Option Container for VEGA

[ThomasAbballe]

Hi all,

In my recent developments for Systus, I introduced various options. Where the "command line" part of it is quite straightforward (thanks boost!), the corresponding changes into the "ConfigurationParameters" are not.

It is tedious to add a field in ConfigurationParameters.h, and its builder, each time I add an option. I am not saying it's very time-consuming, but it seems to me there should be a better approach to this problem.

Anybody has an idea on this?

[ldallolio]

Hi Thomas, ConfigurationParameters was designed to handle a user configuration : the main idea is that you can specify your preferences by using a configuration file in your home directory, or by using command line parameters. This work was not completed since its creator left the project. Another point is that Vega, by design, should have a limited quantity of parameters and should not expose the majority of choices available for a specific solver, for many reasons. Vega should automatically choose the "best" set of parameters for the output solver based on the analysis of the specific study, as a human user would do. The parameters should be generic, let's say for example : "emulate or not RBE3 using DDL" (for any code) and not "use this magical Abaqus feature" etc. Of course, different minds will have different opinions about this :-)

[ThomasAbballe]

Hi Luca,

The part reading and interpreting command line, or a configuration file, is great. It's the "handler" ConfigurationParameter which I find, well, cumbersome to extend. It's not urgent, I just put my thought on it here, for posterity.

On the more general topic of options, I am all in favor for "automatically choosing the best set of options" but I like giving the user the choice for two reasons :

• Different users have different (and sometimes very strange) needs. To only allow for a "perfect" translation is, in my opinion, to restrict the capacities of the tool. Better to do an option with a default value of "auto".
• A reliable automatization is tricky and very time-consuming to develop. As we are very limited on our ressources, I much prefer a simple rule, and an option to override the rule if needed.

To stay on your example, "Emulate a RBE3 using DDL" does not seem generic to me, as it is linked to Nastran. It's what i call a "reader option" : something read in Nastran should be translated in X or Y way, whatever the writer. For my development, I mainly implemented "Writer Options" : whatever the reader, something should be translated this way on Systus. As you say, different minds, different solutions ;)

[ldallolio]

Hi Thomas,

I understand what you mean, in fact this was exactly my opinion at about your age and I am still not too far from it :-) I do not remember anything in particular about the "handler", it might have been written like this in an effort to avoid recompilation of unchanged parts (it was an issue when using Boost::Spirit). I suppose that we could simplify all this with no consequences.

"Emulate a RBE3 using DDL" is as you say a multiple reader/multiple writer options : many codes have RBE3 (Nastran, Abaqus, Ansys, Systus, Aster, ...). My suggestion is, whenever it is possible, to think of options in the more general way possible : if the user needs the translation of some analysis, this might be useful for other writers too... In any case, beware of the Zawinski's law :-p

[ldallolio-irt]

ModelConfiguration has been improved in 5950cebed109617f9999d913be6cb51f7fe9e4aa will probably change something in Configuration parameters too in the near future

[ThomasAbballe]

We still need to add a field to ModelConfiguration each time we want to define a new option. Ideally, I would prefer something akin to po::options_description commandLine(), that we use to define options of the vega command. But that's not very important. The improvement of ModelConfiguration is clear and useful enough.