Skip to content
Snippets Groups Projects
  1. Mar 06, 2015
  2. Mar 02, 2015
  3. Feb 22, 2015
  4. Feb 14, 2015
  5. Feb 13, 2015
  6. Feb 06, 2015
  7. Feb 05, 2015
  8. Feb 04, 2015
  9. Jan 30, 2015
  10. Jan 20, 2015
  11. Jan 19, 2015
  12. Jan 14, 2015
  13. Nov 02, 2014
  14. Aug 16, 2014
  15. Jul 30, 2014
  16. May 21, 2014
  17. Apr 26, 2014
  18. Apr 07, 2014
  19. Apr 06, 2014
  20. Mar 27, 2014
  21. Mar 13, 2014
  22. Mar 03, 2014
  23. Mar 02, 2014
  24. Feb 07, 2014
  25. Jan 29, 2014
  26. Dec 18, 2013
  27. Dec 03, 2013
    • Christophe Geuzaine's avatar
      Changed behaviour of DefineConstant & co for better symmetry between GetDP/Gmsh · 743ee706
      Christophe Geuzaine authored
      and Python onelab clients.
      
      WARNING WARNING WARNING: This is a major change -- all our onelab-enabled .geo
      and .pro files will need to be (slightly...) modified.
      
      What's new:
      
      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.
      
      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 local getdp/gmsh variable name (which would change the onelab name
         automatically)
      
      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.
      
      
      743ee706
  28. Oct 02, 2013
  29. Sep 26, 2013
  30. Sep 25, 2013
  31. Sep 23, 2013
  32. Sep 21, 2013
  33. Sep 17, 2013
  34. Sep 03, 2013
Loading