dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #11878
Re: FunctionSpace error in python
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
> form compilers
> should add version number and relevant compiler options to the signature.
>
> As it is now there is no consistency check that checks that Dolfin and
> Instant employ
> the same compiler, (compiler flags), swig etc. This could also be added, I
> assume that
> at some point problems related to this will appear.
>
> Kent
>
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
Follow ups
References