dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Mar 10, 2011 at 12:01:57PM -0800, Johan Hake wrote:
> On Thursday March 10 2011 11:57:06 Anders Logg wrote:
> > On Thu, Mar 10, 2011 at 11:25:08AM -0800, Johan Hake wrote:
> > > On Thursday March 10 2011 11:21:42 Anders Logg wrote:
> > > > On Thu, Mar 10, 2011 at 11:19:38AM -0800, Johan Hake wrote:
> > > > > On Thursday March 10 2011 11:17:37 Anders Logg wrote:
> > > > > > On Thu, Mar 10, 2011 at 10:48:41AM -0800, Johan Hake wrote:
> > > > > > > On Thursday March 10 2011 10:39:19 Anders Logg wrote:
> > > > > > > > On Thu, Mar 10, 2011 at 10:29:46AM -0800, Johan Hake wrote:
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > It should now be possible to set the swig binary and the path
> > > > > > > > > seperatly in the
> > > > > > > > >
> > > > > > > > > Python interface of DOLFIN. I have added two new parameters
> > > > > > > > > which defaults
> > > > > > >
> > > > > > > to:
> > > > > > > > >   parameters["swig_binary"] = "swig"
> > > > > > > > >   parameters["swig_path"] = ""
> > > > > > > > >
> > > > > > > > > If the binary name is in the PATH, just use the "swig_binary"
> > > > > > > > > parameter but if you have you own obscure place for it set
> > > > > > > > > the path too.
> > > > > > > > >
> > > > > > > > > Please test it...
> > > > > > > > >
> > > > > > > > > We also need to figure out how to patch the release of DOLFIN
> > > > > > > > > to be included in Debian, as we then envision to use swig2.0
> > > > > > > > > as binary. Should this be altered in globalparameters.py
> > > > > > > > > where it is added, or into a seperate
> > > > > > > > > global_parameter_file.xml which is handed together with the
> > > > > > > > > distribution.
> > > > > > > > >
> > > > > > > > > I also wondered if we should flesh out the JIT releated
> > > > > > > > > parameters from FFC into its own dictionary. Now they polute
> > > > > > > > > the generated code for no reason.
> > > > > > > >
> > > > > > > > How do you mean?
> > > > > > >
> > > > > > > Now all parameters in the FFC parameters dict are included with
> > > > > > > their values in the generated .h/.cpp files. As this part has
> > > > > > > noting to do with JIT compilation, it is not nessesary to
> > > > > > > include these in the actuall generated code.
> > > > > >
> > > > > > Why not? Those were the parameters used to generate the code.
> > > > >
> > > > > My point is that the actuall code is not dependent on the swig binary
> > > > > that will or will not be used to eventually compile it.
> > > >
> > > > So you mean the swig binary parameters polute the code? ok, so the
> > > > result might be that if someone changes the swig binary, then that
> > > > might trigger a recompilation. Is that so much of a problem?
> > >
> > > Nope!
> > >
> > > But:
> > >   1) Yes, it polutes the code
> > >   2) We need to regenerate reference code each time we add a JIT
> > >   dependent
> > >
> > >      parameter. I got some headeach with merging with main because of
> > >      this...
> > >
> > > No big deal...
> > >
> > > > > > > However they need to be included in the signature string, when
> > > > > > > JIT compiling of course. I might envision something like
> > > > > > >
> > > > > > >   parameters
> > > > > > >   jit_parameters
> > > > > > >
> > > > > > > where the parameters controlls the generation of code and
> > > > > > > jit_parameters controlls the generation of swig module and the
> > > > > > > compilation flags of the code.
> > > > > >
> > > > > > Yes, but I don't see the problem of also including them in the
> > > > > > generated code. When compiling from the command-line, it's nice to
> > > > > > be able to look at the code to see which parameters were used. Why
> > > > > > should we have a special option to not include the parameters when
> > > > > > called from a JIT compiler?
> > > > >
> > > > > The JIT compiler is never used from the command line interface.
> > > >
> > > > No, but the same code generator (FFC) is used both from the
> > > > command-line and from the JIT compiler.
> > >
> > > Sure. But the code is not available for inspection for the used anyway if
> > > he calls it from the JIT interface.
> >
> > True, but to me that sounds like an argument for doing nothing: the
> > user won't see the code anyway so the code can stay the same (no
> > special case needed for when it is called from a JIT compiler).
> >
> > But I see the point of not needing to update the references when a
> > parameter is added which does not affect the generated code. The
> > question is whether we expect that to happen often so it would be
> > worth changing the parameter handling in FFC + DOLFIN and regenerate
> > the references once more...
>
> I am over the pain now, so no big deal... Next time I just have to do it when
> no one elase is regenerating the references at the same time.

ok.

--
Anders