Refactoring of meta::inputparameters (Defect #683)


Added by Christopher Pinke about 4 years ago. Updated almost 4 years ago.


Status:In Progress Start date:01 Jun 2014
Priority:Normal Due date:
Assignee:Matthias Bach % Done:

30%

Category:-
Target version:-

Description

Currently, the inputparameters are in one big file, which makes this class confusing.
In addition, it does not help users to see all possible parameters when they only need some for a concrete executable.


Associated revisions

Revision a0373f37
Added by Christopher Pinke about 4 years ago

re-arranged parameters roughly in categories
refs #683

Revision 96f64440
Added by Christopher Pinke about 4 years ago

put parameter categories into own objects
refs #683

Revision 045dd3aa
Added by Christopher Pinke about 4 years ago

moved hmc parameters into own file
refs #683

Revision 14a24e81
Added by Christopher Pinke about 4 years ago

improved unit tests linking in meta
refs #683

Revision 724ff7ff
Added by Christopher Pinke about 4 years ago

added hmc parameters class
refs #683

Revision 9186e8d9
Added by Christopher Pinke about 4 years ago

moved hmc parameters to own file
refs #683

Revision 0b59b513
Added by Christopher Pinke about 4 years ago

added options to hmc parameters class
refs #683

Revision e57d05a0
Added by Christopher Pinke about 4 years ago

moved Rhmc parameters to own file
refs #683

Revision 764f9b47
Added by Christopher Pinke about 4 years ago

moved rhmc options to class
refs #683

Revision 2302a1c4
Added by Christopher Pinke about 4 years ago

refactoring
refs #683

Revision a114614d
Added by Christopher Pinke about 4 years ago

moved observable parameters to own file
refs #683

Revision d3e69f77
Added by Christopher Pinke about 4 years ago

moved test parameters to own class
refs #683

Revision 12e447d6
Added by Christopher Pinke about 4 years ago

moved IO parameters to own class
refs #683

Revision 8a85b628
Added by Christopher Pinke about 4 years ago

moved config parameters to own class
refs #683

Revision 2d85821e
Added by Christopher Pinke about 4 years ago

moved fermion parameters to own class
refs #683

Revision 53ed9352
Added by Christopher Pinke about 4 years ago

moved solver parameters to own class
refs #683

Revision 7ab855a4
Added by Christopher Pinke about 4 years ago

moved source parameters to own class
refs #683

Revision 21a96eeb
Added by Christopher Pinke about 4 years ago

moved gauge parameters to own class
refs #683

Revision 8e7fac0d
Added by Christopher Pinke about 4 years ago

moved heatbath parameters to own class
refs #683

Revision 1e6ef320
Added by Christopher Pinke about 4 years ago

added the possibility for subsets of parameters
refs #683

Revision fcf86fb6
Added by Christopher Pinke about 4 years ago

added different parameter sets to executables
refs #683

History

Updated by Christopher Pinke about 4 years ago

I moved the options and the parameters themselves to own classes.

The assignment of the single parameters to these classes has to be checked again as some are probably beeter suited for other classes.
Then, the rest of the constructor in inputparameters has to be refactored.

In addition, it might be non-trivial to refactor the conversion from strings to the enum-types as well as the aliases!
Here, the best thing would be to have a vector of ParametersBasic *, and on each one calls the appr. fct. in turn.
However, I dont know how then the parameters of the spec. classes should be member of inputparameters without making two kinds of objects...

  • Status changed from New to In Progress
  • % Done changed from 0 to 30

Updated by Matthias Bach almost 4 years ago

Please note that I slightly modified your clases. I forbid copying to prevent slicing and I made sure the options_descriptions are returned by reference. If the are no longer alive if the options are parsed, behaviour is undefined. This showed in the su3vec tests. See 8be25a7cc540f23acf3c3b0ee04a4c8819d659c7 for details.

Updated by Christopher Pinke almost 4 years ago

Thanks for the fix, Matthias. I am glad that the bug showed up, I did not have a problem with that, which was propably luck.
The changes were done prior to the lattice conference, so it might also be that any compiler warning got lost due to that.

However, the "problem" of the structure of the inputparameters is a bit complicated.
As it is now, the inputparameters class selects the parameters appropiate for a given executable, so that a user only sees those.
But the object inputparameters object itself has all available parameters, including getters and setters.
So basically, all functionality is always there, but a part may be hidden from the user.
The problem is that if at some point in the code some parameter is requested, it is a priori not known if this parameter is actually availabe to the user. This may be related to a too high interconnection in the code in general and may cause some problems.

Do you have any idea how to improve this?

  • Assignee changed from Christopher Pinke to Matthias Bach

Also available in: Atom PDF