← Back to team overview

dolfin team mailing list archive

Re: FunctionSpace error in python

 

On fr., 2009-01-23 at 15:31 +0100, Martin Sandve Alnæs wrote:
> On Fri, Jan 23, 2009 at 3:23 PM, Kent Andre <kent-and@xxxxxxxxx> wrote:
> > On fr., 2009-01-23 at 14:21 +0100, Martin Sandve Alnæs wrote:
> >> On Fri, Jan 23, 2009 at 2:16 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> >> > On Friday 23 January 2009 14:02:31 kent-and@xxxxxxxxx wrote:
> >> >> > On Fri, Jan 23, 2009 at 1:33 PM,  <kent-and@xxxxxxxxx> wrote:
> >> >> >>> On Fri, Jan 23, 2009 at 12:40:21PM +0100, Johan Hake wrote:
> >> >> >>>> On Friday 23 January 2009 12:15:51 Martin Sandve Alnæs wrote:
> >> >> >>>> > On Fri, Jan 23, 2009 at 12:00 PM, Johan Hake <hake@xxxxxxxxx> wrote:
> >> >> >>>> > > On Friday 23 January 2009 11:54:50 Martin Sandve Alnæs wrote:
> >> >> >>>> > >> On Fri, Jan 23, 2009 at 11:48 AM, Johan Hake <hake@xxxxxxxxx>
> >> >> >>>>
> >> >> >>>> wrote:
> >> >> >>>> > >> > On Friday 23 January 2009 11:27:31 Ola Skavhaug wrote:
> >> >> >>>> > >> >> On Fri, Jan 23, 2009 at 10:32 AM, Johan Hake <hake@xxxxxxxxx>
> >> >> >>>>
> >> >> >>>> wrote:
> >> >> >>>> > >> >> > On Friday 23 January 2009 10:09:12 Martin Sandve Alnæs
> >> >> >>>>
> >> >> >>>> wrote:
> >> >> >>>> > >> >> > > On Fri, Jan 23, 2009 at 9:39 AM, Johannes Ring
> >> >> >>>> > >> >> > > <johannr@xxxxxxxxx>
> >> >> >>>> > >> >> >
> >> >> >>>> > >> >> > wrote:
> >> >> >>>> > >> >> > > > On Thu, January 22, 2009 19:10, Johan Hake wrote:
> >> >> >>>> > >> >> > > >> On Thursday 22 January 2009 17:02:41 A Navaei wrote:
> >> >> >>>> > >> >> > > >>> Johan,
> >> >> >>>> > >> >> > > >>>
> >> >> >>>> > >> >> > > >>> Thanks, instant-clean did the trick! Maybe this should
> >> >> >>>>
> >> >> >>>> be
> >> >> >>>>
> >> >> >>>> > >> >> > > >>> somehow automated.
> >> >> >>>> > >> >> > > >>
> >> >> >>>> > >> >> > > >> Yes, I have thought about it.
> >> >> >>>> > >> >> > > >>
> >> >> >>>> > >> >> > > >> Is it possible to add a call to instant-clean in the
> >> >> >>>>
> >> >> >>>> install
> >> >> >>>>
> >> >> >>>> > >> >> > > >> script of the ffc
> >> >> >>>> > >> >> > > >> and dolfin packages Johannes?
> >> >> >>>> > >> >> > > >
> >> >> >>>> > >> >> > > > Yes, it is possible to add post installation scripts to
> >> >> >>>>
> >> >> >>>> the FFC
> >> >> >>>>
> >> >> >>>> > >> >> > > > and DOLFIN packages (and perhaps Instant) that runs
> >> >> >>>> > >> >> > > > instant-clean. Should I add this?
> >> >> >>>> > >> >> > > >
> >> >> >>>> > >> >> > > > Johannes
> >> >> >>>> > >> >> > >
> >> >> >>>> > >> >> > > Can you add it to SyFi as well please? But we don't want
> >> >> >>>>
> >> >> >>>> this in
> >> >> >>>>
> >> >> >>>> > >> >> > > development versions though, we should at least have an
> >> >> >>>>
> >> >> >>>> option
> >> >> >>>>
> >> >> >>>> > >> >> > > to avoid it.
> >> >> >>>> > >> >> >
> >> >> >>>> > >> >> > I think it will be sufficient to add the automatic cleaning
> >> >> >>>>
> >> >> >>>> in
> >> >> >>>> the
> >> >> >>>>
> >> >> >>>> > >> >> > ubuntu scripts.
> >> >> >>>> > >> >> >
> >> >> >>>> > >> >> > I can add the swig version to the signature generation in
> >> >> >>>>
> >> >> >>>> ffc
> >> >> >>>> and
> >> >> >>>>
> >> >> >>>> > >> >> > dolfin.
> >> >> >>>> > >> >> >
> >> >> >>>> > >> >> > While on the topic, does instant check whether swig is
> >> >> >>>>
> >> >> >>>> installed,
> >> >> >>>>
> >> >> >>>> > >> >> > when a module is built? Also I have on several occasions now
> >> >> >>>> > >> >> > checked for the swig version. Should I put this code in
> >> >> >>>>
> >> >> >>>> instant,
> >> >> >>>>
> >> >> >>>> > >> >> > e.g.
> >> >> >>>> > >> >> >
> >> >> >>>> > >> >> >   check_swig_version("1.3.35")
> >> >> >>>> > >> >> >
> >> >> >>>> > >> >> > It will return false if the current swig version is lesser
> >> >> >>>>
> >> >> >>>> than
> >> >> >>>>
> >> >> >>>> > >> >> > "1.3.35"? I think it would be natural for instant to provide
> >> >> >>>>
> >> >> >>>> such a
> >> >> >>>>
> >> >> >>>> > >> >> > function.
> >> >> >>>> > >> >>
> >> >> >>>> > >> >> There is a related problem that needs to be adressed here. If
> >> >> >>>>
> >> >> >>>> you
> >> >> >>>>
> >> >> >>>> > >> >> build an extension of a module wrapped with version x of swig,
> >> >> >>>>
> >> >> >>>> you
> >> >> >>>>
> >> >> >>>> > >> >> should require the same version of swig in instant. Perhaps
> >> >> >>>>
> >> >> >>>> the
> >> >> >>>>
> >> >> >>>> > >> >> check_swig_version("1.3.35") should only return true if you
> >> >> >>>>
> >> >> >>>> have
> >> >> >>>>
> >> >> >>>> > >> >> exactly that version. Another function, a-la
> >> >> >>>> > >> >>
> >> >> >>>> > >> >> assert_swig_min_version("1.3.35")
> >> >> >>>> > >> >
> >> >> >>>> > >> > This could probably be kept in one function. By default the
> >> >> >>>>
> >> >> >>>> function
> >> >> >>>>
> >> >> >>>> > >> > returns whether a version of swig is equal or greater than the
> >> >> >>>> > >> > prescribed version, and:
> >> >> >>>> > >> >
> >> >> >>>> > >> >   check_swig_version("1.3.35", equal = True)
> >> >> >>>> > >> >
> >> >> >>>> > >> > will return true only if the version is the same as the
> >> >> >>>>
> >> >> >>>> prescribed
> >> >> >>>>
> >> >> >>>> > >> > one?
> >> >> >>>> > >> >
> >> >> >>>> > >> > The assertion functionality will then be handled by the
> >> >> >>>>
> >> >> >>>> function
> >> >> >>>> that
> >> >> >>>>
> >> >> >>>> > >> > use instant, i.e., ffc, sfc, dolfin compile_function a.s.o.
> >> >> >>>> > >>
> >> >> >>>> > >> But FFC isn't compiled with SWIG. Dolfin will have to do that,
> >> >> >>>>
> >> >> >>>> for
> >> >> >>>>
> >> >> >>>> > >> example at import time.
> >> >> >>>> > >
> >> >> >>>> > > No, but it produces code that is compiled with swig. And this code
> >> >> >>>>
> >> >> >>>> should
> >> >> >>>>
> >> >> >>>> > > be compiled with the same swig version that dolfin is compiled
> >> >> >>>>
> >> >> >>>> with.
> >> >> >>>> Then
> >> >> >>>>
> >> >> >>>> > > dolfin need to hand its swig version to ffc when it is using it so
> >> >> >>>>
> >> >> >>>> ffc
> >> >> >>>>
> >> >> >>>> > > can check which version is installed while swigging compiled
> >> >> >>>>
> >> >> >>>> forms.
> >> >> >>>> If
> >> >> >>>>
> >> >> >>>> > > this version is not the same as the handed version from dolfin ->
> >> >> >>>>
> >> >> >>>> raise
> >> >> >>>>
> >> >> >>>> > > error.
> >> >> >>>> >
> >> >> >>>> > In my opinion,
> >> >> >>>> >
> >> >> >>>> >   dolfin gets its swig version
> >> >> >>>> >   dolfin calls instant to check whether it's compatible with the
> >> >> >>>>
> >> >> >>>> current
> >> >> >>>>
> >> >> >>>> > swig
> >> >> >>>> >
> >> >> >>>> > is simpler than
> >> >> >>>> >
> >> >> >>>> >   dolfin gets its swig version
> >> >> >>>> >   dolfin passes its swig version to ffc
> >> >> >>>> >   ffc calls instant to check whether it's compatible with the
> >> >> >>>>
> >> >> >>>> current
> >> >> >>>> swig
> >> >> >>>>
> >> >> >>>> > why pass the info to ffc at all? It would need to be handled in
> >> >> >>>>
> >> >> >>>> dolfin
> >> >> >>>>
> >> >> >>>> > for function compilation anyway. If dolfin checks that the current
> >> >> >>>> > swig is compatible with the version it was compiled with at import
> >> >> >>>> > time, it doesn't have to be checked anywhere else. With your model,
> >> >> >>>> > both DOLFIN, FFC and SFC would need to be modified.
> >> >> >>>>
> >> >> >>>> Sounds reasonable. Dolfin defines it own jit function and the check
> >> >> >>>> could be
> >> >> >>>> added here.
> >> >> >>>>
> >> >> >>>> We will still have the problem for older forms, which are allready in
> >> >> >>>> the
> >> >> >>>> cache and are compiled with an older swig. Putting the swig version in
> >> >> >>>> the
> >> >> >>>> signature would prevent this to happen though.
> >> >> >>>>
> >> >> >>>> Johan
> >> >> >>>
> >> >> >>> I think we should throw as much as possible into the signature, just
> >> >> >>> to make sure. DOLFIN passes some signature prefix to the form compiler
> >> >> >>> (which could be the DOLFIN version and the SWIG version), then the
> >> >> >>> form compiler adds whatever it feels to add to the signature (form
> >> >> >>> signature, form compiler name and form compiler version), then Instant
> >> >> >>> adds whatever it feels like adding.
> >> >> >>>
> >> >> >>> --
> >> >> >>> Anders
> >> >> >>
> >> >> >> Ok, so Instant should add Swig version to the signature. Dolfin and the
> >> >> >
> >> >> > No, as Johan pointed out, Instant can't add to the signature. Instant
> >> >> > will either construct its own signature from the files and options it
> >> >> > gets, or use the provided signature as-is. So the form compilers
> >> >> > should add whatever they need to the signature.
> >> >> >
> >> >> > Martin
> >> >>
> >> >> But the form compilers / Dolfin do not know which SWIG version Instant
> >> >> will use
> >> >> (although this might not be a big issue since it is probably basically the
> >> >> same process
> >> >> that decides on which SWIG to use in both cases).
> >> >
> >> > The form compiler/dolfin can get the present swig version (instant can provide
> >> > a function swig_version()?), which will be used to compile a signature.
> >>
> >> Exactly.
> >>
> >> >> Anyway, this is really independent of Dolfin and the compilers. What
> >> >> should Instant
> >> >> do eg. if SWIG has been updated since the last time it inlined the exact
> >> >> same code?
> >> >
> >> > I think Instant should just do what it is told to. Any checks need to be done
> >> > in the caller of instant.
> >>
> >> Exactly. And we can add the swig version if instant creates the
> >> signature itself.
> >>
> >> >> Should it just import the module or regenerate it?
> >> >
> >> > Then ffc/dolfin will provide a different signature and a new module will be
> >> > compiled.
> >>
> >> Exactly.
> >>
> >> Martin
> >
> >
> > ok, no changes to instant then :)
> >
> > Kent
> 
> No, in instant we should
> 1) implement the swig version utility functions

I agree on this. 

> 2) add the swig version to the signature it creates itself if the user
> doesn't provide one.

Well since none of us use this, it is not important. It might not 
even be the right thing to do. 

Kent





References