Flexsim vs. Delmia (Quest)

Hello,


I put this thread under Q&A because it gets more traffic. I have never used Delmia (Quest) before- only FlexSim. I was asked to highlight the strengths and weaknesses of both. I have no basis of comparison. Can anybody help here?


Thanks

Hi Gavin,

I first picked up FlexSim when version 3 was out, about 3-4 years ago. I only used it briefly while in college. I got my first job out of school using QUEST and have been using that for a little over two years. During that time I have been able to learn quite a lot about how the logics work and how to automate different functionality in QUEST. I just seriously started trying to learn to build powerful models in FlexSim about two weeks ago, so my knowledge of FlexSim doesn't go as deep as for QUEST.

Here's a list I've put together with some comparisons, hopefully it'll help you (FS=FlexSim,Q=QUEST):

FS:c++/flexscript scripting/logic languages - Lower level, more flexible, seems faster (I haven't done any real speed test comparisons)
Q:BCL/SCL scripting/logic languages = Higher level than FlexSim, seems to run slower with complex logic

FS: overall architecture difference: TaskExecuters and FixedResources which can be customized easily and used to create new element types
Q: overall architecture difference: Element Classes - object classes which make identical instances - easily model different number of machines, labors, etc...however, it's less flexible, and you have to mess with different element types to get advanced functionality

FS:uses flowitems which vary only based on display geometry (I think)
Q:uses part classes, which can hold process routing information, required routing labor, display parameters

FS:logics run on events
Q:logics run constantly throughout model (not on events) which can be more flexible than FlexSim (although usually you end up waiting for some event anyway)

FS:better community of users - very active, very knowledgeable
Q:much smaller community of users, less active - small delmia group on Google groups

FS:you have to write custom logic in order to have different part types go through a machine with different cycle times
Q: process sequence can be stored within a part class so routing is encapsulated in part class, no code required

FS:custom code required for routing different parts through different machines - but can be more easily changed through use of routing tables
Q:easy to assign different operator classes to different processes. Process objects can reference to any machine class.
(Note:I think this is something FlexSim could implement without any major changes

FS:logic is embedded in FlexSim nodes, which makes code reuse more difficult (unless there is an easy way to reference external files/previously used code)
Q:logic is saved in external files which make it easier to reuse code but also easy to break existing functionality

FS: one file is all that's needed for running a model (aside from geometry)
Q:to move a model to another computer you need to send all required files - easy-ish to do with model archiving function that compresses all required files into one file - including geometry

FS:easy to use nice looking photo textured 3d models in standard formats
Q:more extensive 3d file import/export options, have to manually apply textures, though

FS:OLE link to Excel makes it easier to interact with spreadsheet data
Q:easy use of text file input/output for interacting with spreadsheet data

FS:~26 standard distributions, multiple random number streams (with, I believe, antithetic random number generation)
Q:~11 standard distributions, multiple random number streams (no antithetic random number generation)

FS:result reporting - much more visually attractive from what I've seen, probably easier to interpret than quest
Q:result reporting - graphing more cumbersome to create, possibly more variety than FlexSim has...text based reporting only

FS:failures & shifts more cumbersome to assign
Q:failures and shifts easy to create and assign to multiple machines...seems easier to assign repair processes too (easier to reuse process objects)

I think QUEST is better suited for large scale models, as in my experience the graphics hold up much better in QUEST as model size grows. Also it seems easier to import 2D layouts from CAD...it seems FlexSim has more trouble than QUEST.

However, FlexSim is much more active in terms of development and community. Delmia isn't putting a lot of effort towards developing QUEST, as they're more focused on their V5 and V6 platforms (not discrete-event simulation tools). However, QUEST is a very powerful, flexible simulation tool. So is FlexSim. I would say that at this point it's easier to build large scale models in QUEST, both through the UI as well as through automation. This is mainly because Quest’s UI is more mature, and I'm sure FlexSim will catch up in no time. However, the higher level BCL/SCL languages are much easier to learn for non programmers, in my opinion, which makes it easier to script the building of large models.

I would say it's very tough to decide which package is better. Each certainly has its strengths and weaknesses, and to be honest, I'm glad that I'm fortunate enough to have both to use.

I hope I haven't rambled too much, and if you have any questions about QUEST, you can email me at jfournier at ccat.us, or you can go to our QUEST group on Google Groups at http://groups.google.com/group/delmia_quest?hl=en

Great Post! Can you explain antithetic random number generation a bit?

My limited knowledge of the subject of antithetic random number generation is that it's a variance reduction technique that enables you to see the effect the random number generation has on the output of your model.

Random number generators only produce a number between 0 and 1 usually, and apply a distribution to that number. With antithetic generation, you run the simulation using the regular random number generator. You then run it again using the same random number streams and seeds, but using the antithetic generator. Basically the antithetic generator returns the complement of the number the regular generator returns (so 0.35 becomes 0.65, etc...).

This will reduce the variance of the output of the simulation, basically eliminating randomness caused by random number generation. So this way you can see the effect of the random number generator on your output, and I think you can also use a smaller number runs and still get valid, useful output.

If anyone has a better explanation, or if I was wrong, please chime in.

http://www.jstor.org/pss/2629959

-Jon