dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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.

Johan

> --
> Anders