[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITP: aster -- Finite Element Analysis (FEA) software for engineering simulations

Hello Andrea,

On Tue, 2011-05-10 at 12:58 +0100, Andrea Palazzi wrote:
> --- Mar 10/5/11, Adam C Powell IV <hazelsct@debian.org> ha scritto:
> > Da: Adam C Powell IV <hazelsct@debian.org>
> > Oggetto: Re: ITP: aster -- Finite Element Analysis (FEA) software for engineering simulations
> > > > I would like to help in packaging the Code Aster
> > software[1] for Debian.
> > > Thanks for your interest in the packaging of Code
> > Aster.
> > > However, you should be aware of a license issue with
> > metis-edf:
> > > http://glaros.dtc.umn.edu/gkhome/node/686
> > > To unblock, we should consider some uploads in
> > non-free and contrib.
> > 
> > How extensive are the differences between metis-edf and
> > metis?  Might it
> > be worth porting those differences to Scotch?  Or does
> > Code Aster use
> > some features of metis not present in Scotch, like
> > element-wise
> > partitioning (instead of node-wise)?
> Hi,
> I know nothing about mesh partitioning, scotch and metis; however here is
> what Cristophe Trohime said to me when we talked about this a month ago
> (the quoted text is mine):
> "[...]> As far as I understand, it's actually possible to build CA without
> > metis; however some functionalities will not be available
> > (RENUM='METIS' in SOLVEUR), and this can be a rather annoying
> > problem, since metis is the default renumerator; however,
> > if CA can switch automatically to another renum, this may
> > become just a performance issue (and a longer list of failing
> > tests, if METIS is explicitly called).
> > For replacing metis with scotch, the library by itself is already
> > there (libscotchmetis), however what is missing are the executables:
> > see this thread http://www.code-aster.org/forum2/viewtopic.php?id=14417 
> > , where André says "In case you succeed to make the tests from 
> > liste_internet pass with scotchmetis, I am very interested about your 
> > build (because it means that you can supply an alternative to onmetis, 
> > kmetis and onmetis.exe)."
> I had the opportunity to discuss that with Mathieu Courtois, a ASTER developper, last year.
> He tells me that if we choose Scotch instead of metis it will be better to call directly without using any additionnal programs. But my guess is this is a lot of work.
> The other point is if you want to rewrite (on)metis with scotch you cannot do it easily.
> They are using some calls to metis which do not exist in scotch.
> As far as I understand they prefer to stick to metis which is more widespread than scotch. [...]"
> So, if I get it right CA calls metis via an executable (onmetis,
> konmetis, onmetis.exe).

Great, that way there's no derivative work and no copyright violation,
as there would be if they linked to libmetis (at least in the FSF

> The difference between metis and metis-edf
> is (i think) in these executables and in some other modification to
> make it work with CA - maybe the int32/int64 issue.
> Those executables are using some library calls that are not implemented
> in scotch, and EDF doesn't seems interested to replace metis with scotch.

Ah, that's what I was afraid of.  This is an issue also for Elmer,
though Elmer has an option for node-wise partitioning, which Scotch
supports, and which I enable by default, so it works out-of-the-box.  If
an Elmer user switches that off, they get an error message.

Thanks for this additional information.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: