Settings class

[Andreas Ipp]

With the recent problem of initialization in mind when pressing the "reset" button, I wonder whether it is good to have mutable objects in the settings class:

If you call:

new Simulation(settings);

and then press "reset" and call again

new Simulation(settings);

then some of the classes may have been modified by the simulation in the meantime (for example a CombinedForce class, etc.), and the second simulation may not be the same as the first.

The problem could be avoided if the settings class only consists of immutable objects (Strings) or primitive data types.

Does this make sense?

[Jan Kis]

I agree with the idea that the new settings class should not contain mutable objects so that we can easily call "new Simulation(settings)" multiple times and get the same simulation.

On the other hand, I am not in favor of using just plain strings as placeholders for some other real objects. If we did so we might and up with code as following.

if (settings.solver.equals("Boris")) {

  solver = new Boris();

}

If such a code is spread all over the place then changing the class name to something else eg. Boris2 would cause a need to change all the string comparisons. In short, it seems not to be very extensible and easy to use. If we do end up with just pure strings then I strongly suggest to keep all string comparisons needed to find out the actual class in one place. (Furthermore, depending too much on strings is not considered a good OOP design). 

Instead I am in favor of creating immutable objects right from the beginning (this is also a very good programming practice as an immutable class is quite impossible to be broken by a client code which uses it). Currently, we are not so far from this. Eg. the solvers are immutable as far as I know. The only mutable objects which need to be in the settings class are grid and combined force.

The combined force does not really need to be in the settings class, we need there a list of forces from which the combined force in the simulation should be constructed.

As far as the grid class is concerned, I suggest to further split it into a simple field holder without any interpolator and field solver. Consequently, we do not need to store it in the settings class. It is just the interpolator and field solver which we need and they seem to be quite immutable at the moment. (This is not the only reason to split the grid class, I think that with further thoughts about the boundaries and parallelization it might get quite a lot of responsibility even without the interpolator and field solver).

[Jan Kis]

Hi Guys,

i would like to stress the importance of creating new setting class with default simulation parameters.

Why do we need the settings class?

1) Right now it is quite unclear which objects are instantiated in the simulation class. Simulation creates some default values in its constructor, so does the grid. Later on in InitialConditions we overwrite some of these values with new values. Consequently, it is hard to tell for example what kind of field solver are we really using. Furthermore, it is very hard to determine the default value reliably since we are changing it at different places.

2) With the settings class we can easily introduce the possibility of setting the simulation parameters on command line or in a settings file.

3) When I am refactoring some code I often need to change every single method in the IntialConditions class. If we had a setting class, then all the different methods in InitialConditions can be replaced with different setting files and a single method for parsing the file. Thus, changes need to be done only to one method.  

What do we require from the settings class?

1) It needs to specify default values for simulation parameters.

2) It should not change throughout the simulation (as Andreas wisely mentioned), so that we can easily rerun the simulation.

3) It should be able to parse the command line.

4) It should be able to parse a file.

If I am missing something, please add it.

How can such a simulation class look like?

See the attachment for the prototype of the settings class. If you see some crucial problems with the prototype please mention them.

I believe Kirill wanted to tackle this problem. If you are happy with the enclosed prototype I would very much appreciate if I can use it in the code of the distributed version I am writing now. Once Kirill starts working on the problem he can add the further non-trivial functionality. 

Cheers,

Jan

[Andreas Ipp]

Looks good, so please proceed with your solution.

(One thing to note is that the classes created within the Settings class are not really immutable. For example, I could change the Bz-field of the ConstantForce within the CombinedForce obtained using Settings.getForce(). The next time, getForce() is called, one would obtain the modified value of the Bz-field. So, maybe it is better to store the value "private double Bz" directly in the settings class, and create a new ConstantForce on demand in getForce(), with the Bz value. But this is something that can be changed later.)

Am Freitag, 6. Juli 2012 10:38:37 UTC+9 schrieb Jan Kis:

Hi Guys,

i would like to stress the importance of creating new setting class with default simulation parameters.

Why do we need the settings class?

1) Right now it is quite unclear which objects are instantiated in the simulation class. Simulation creates some default values in its constructor, so does the grid. Later on in InitialConditions we overwrite some of these values with new values. Consequently, it is hard to tell for example what kind of field solver are we really using. Furthermore, it is very hard to determine the default value reliably since we are changing it at different places.

2) With the settings class we can easily introduce the possibility of setting the simulation parameters on command line or in a settings file.

3) When I am refactoring some code I often need to change every single method in the IntialConditions class. If we had a setting class, then all the different methods in InitialConditions can be replaced with different setting files and a single method for parsing the file. Thus, changes need to be done only to one method.  

What do we require from the settings class?

1) It needs to specify default values for simulation parameters.

2) It should not change throughout the simulation (as Andreas wisely mentioned), so that we can easily rerun the simulation.

3) It should be able to parse the command line.

4) It should be able to parse a file.

If I am missing something, please add it.

How can such a simulation class look like?

See the attachment for the prototype of the settings class. If you see some crucial problems with the prototype please mention them.

I believe Kirill wanted to tackle this problem. If you are happy with the enclosed prototype I would very much appreciate if I can use it in the code of the distributed version I am writing now. Once Kirill starts working on the problem he can add the further non-trivial functionality. 

Cheers,

Jan