| Thread Previous • Date Previous • Date Next • Thread Next |
On Mon, 6 Jul 2009, Anders Logg wrote:
On Mon, Jul 06, 2009 at 04:01:23PM +0200, Johan Hake wrote:On Monday 06 July 2009 06:01:51 Shawn Walker wrote:Sorry, for the dumb question, but what exactly will this NewParameter system do? What is the big deal? Does it allow one to set parameters in deeply embedded modules or external libraries? Just a short description would be good! :)It's not a dumb question at all! Hopefully the new parameter system will alow users to more easily controll both DOLFIN and any built applications using DOLFIN. A class was previously parameterized using get and set memberfunctions, which hide the actuall storage of the parameters. Global parameters was accessed using dolfin_get and dolfin_set. Now we store the parameters explicitly using the public member parameters, in all classes inheriting Variables.Also note the global (in namespace dolfin) variable named parameters which contains the global parameters for DOLFIN. The more decentralized design also means that we have been able to reduce the number of global parameters to just a few. We can now make more extensive use of parameters in DOLFIN since it's no longer a problem to add a new parameter (it does not have to be global anymore).Each class that want to use the parameters variable defines a static default_parameters method. This method is called in the constructor of the class populating the parameters. The parameters can then be passed to other classes using the first one, or a user can fetch the parameters, building a nested parmeter heirarchy. Such nested parameter set, can be used to parse command options, and/or read parameters from file (I think all implementation is not in place for this though), and be pretty printed to the user. We also have support for simple range checks which makes user code less error prone. Take a look in sandbox/misc/ for a demonstration of the syntax and use in both python and cpp.In particular, note that one may print parameters by info(parameters); // print global DOLFIN parameters info(solver.parameters); // print parameters for solver -- Anders
ok, I wasn't aware of this `parameters' variable. - Shawn
- Shawn On Sun, 5 Jul 2009, Anders Logg wrote:On Sat, Jul 04, 2009 at 07:41:32PM +0100, Garth N. Wells wrote:Anders Logg wrote:On Sat, Jul 04, 2009 at 08:04:36PM +0200, Johan Hake wrote:On Saturday 04 July 2009 19:53:46 Anders Logg wrote:On Sat, Jul 04, 2009 at 05:30:42PM +0200, Anders Logg wrote:On Sat, Jul 04, 2009 at 12:59:19AM +0200, Johan Hake wrote:On Saturday 04 July 2009 00:52:13 Garth N. Wells wrote:Johan Hake wrote:On Saturday 04 July 2009 00:14:04 Garth N. Wells wrote:How should the new parameter system be used from the Python interface?Looks like you found out of it?Yes, with some trial and error and a search on "__setitem__".Yes I used __setitem__ for all assignments. A test is also provided in sandbox/misc Should update it to a fullfledged unit test before the release. I see that I need to update the PyDOLFIN interface for nested parameter set. JohanI've been working without internet access and have worked on removing the old parameter system entirely and using the global parameter set instead of dolfin_get/set. I'll try to merge this later tonight and then I suspect there will need to be some more work on getting this to work in Python.The merge went terribly wrong. We've been editing the same files. I need to reimplement the changes in a fresh clone.Urk... I just touched 5 lines! How could it destroy a whole merge? johanGarth had 10 or so changesets in between, related to handling of parameters in Python, linear algebra and demos. I touched some of that as well, so I might as well redo it.I assumed that the big merge that you warned us about on the list took place yesterday, which I why I committed some changes last night to get a few demos working.This is a reminder of the importance of merging early, often, and that having an internet connection is important when coding... :-). . . and we need to get back on top of the buildbots so we can trace back which changes break things. GarthHow should we deal with situations like this in the future? It's good to try to always keep the buildbots green (never breaking anything) but often cooperation is necessary to get a big change in place, like now with the parameter system when I have been needing help from Garth (to fix parameter logic in for example the uBLAS linear algebra) and Johan (to fix the parameter system in Python). Suggestions? We could have two repositories: dolfin and dolfin-dev and push work in progress to dolfin-dev before we push it to dolfin, but it will be a complication. We could use dolfin (same as now) for most things and push to dolfin-dev when we know something will obviously break._______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev
| Thread Previous • Date Previous • Date Next • Thread Next |
