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. >>>>>>>>>> >>>>>>>>>> Johan >>>>>>>>> >>>>>>>>> I'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? >>>>>>> >>>>>>> johan >>>>>> >>>>>> Garth 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. >>>>> >>>>> Garth >>>> >>>> How 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@fenics.org >>> http://www.fenics.org/mailman/listinfo/dolfin-dev >> >> > _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
