[Getdp] change in onelab for GetDP & Gmsh
cgeuzaine at ulg.ac.be
Tue Dec 3 16:54:10 CET 2013
After long discussions with François and Ruth we changed the behaviour of DefineConstant & co for better symmetry between GetDP/Gmsh and Python onelab clients.
This is a major change: all the onelab-enabled .geo and .pro files need to be (slightly) modified. I have manually changed all the examples in the SVN (for both GetDP and Gmsh) and I will update the files on the onelab.info website tomorrow (once we have new nightly builds).
1. The name of a onelab variable (in the onelab database) is no more constructed
from the name of the corresponding GetDP/Gmsh variable. One now needs to
specify the onelab name explicitely, using the "Name" attribute. The "Name"
is the actual name of the parameter in the onelab database, i.e., it also
includes the path.
This makes the "Path" attribute obsolete (it has no effect anymore). The
"Legend" attribute can still be used (and it can be useful in edge cases,
e.g. when you want a "/" in the name of a onelab paramater), but in most
cases it's not necessary anymore.
2. When a DefineConstant & co is used and no Name is given
(e.g. DefineConstant[a=2]), no onelab parameter is created. This allows to
provide default values to internal parameters without polluting the database.
Why did we change?
1. The new syntax matches what we do in Python, where specifying a name is
mandatory (there's no way around this in Python, as onelab cannot guess the
name of a Python variable to which a onelab parameter value will be assigned).
The change will prevent common mistakes where two parameters with the same
label actually correspond to 2 different onelab parameters, due to a change
in a local GetDP/Gmsh variable name (which would change the onelab name
2. The new syntax allows to nicely decouple onelab parameters from internal
variables with default values, that we don't want in the onelab database.
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science