[needs-packaging] oofem

[GercoKees]

oofem is a free finite element (short: fem) solver for solving mechanical, transport and fluid mechanics problems. It could be used by civil engineers, architects, etcetera. It basically gives you a command driven solver, which reads an input file and creates an output file. The output file can be read with a post processor like oofeg. I create some separate [needspackaging] issues for packaging the related post and preprocessors.
pre: bug #220588DJ
post: bug #220584DK

btw, including the postprocessor is a matter of installing a few extra libraries and then install oofem with the right options...

license: GNU GPL

Website:
http://www.oofem.org/DL

Installation wikipage:
http://www.oofem.org/wiki/doku.php?id=installationDM

I have gone through the hassle of installing this, and if there is anything i can do to help, please let me know!

Thanks in advance.

[Václav Šmilauer (eudoxos)]

Hi, thanks for your e-mail, GercoKees.

I have ckit and elixir packaged in my PPA (https://launchpad.net/~eudoxos/+archive). For both of them, I used the version distributed from the oofem.org as upstream (since the real upstream is (1) not maintained since ages and (2) doesn't work with oofem). I used scons to build and install necessary files, you can see that in the source packages; the reason that I also had troubles with Makefiles and I am fluent with scons.

For oofem (and oofeg) itself, I installed it from sources on my computer, but I had to change a few things in configure.in to e able to pass /usr/local/ as prefix for ckit and elixir and sent the patch upstream; Bořek Patzák applied it to subversion and it will appear in the next release. He is about 1 minute walk from my office and cooperative in this sense.

At that point, my packaging efforts stopped, since I didn't have neither time nor need for troubleshooting the compilation with all the optional dependencies (parmetis, petsc, various MPI variants).

We should define clearly which of these optional features will be enabled, or if we will have multiple binary packages with different flavors (like vim-tiny, vim-gnome etc), one for plain oofem, one supporting MPI with shared memory, one for MPI on clusters (I am not sure whether those are mutually exclusive, for example). Do you have any clear proposition on that?

I will subscribe to this bug so we can keep this discussion publicly here.

Regards, Václav Šmilauer

[GercoKees (gercokees)]

Hi,
Personally i only use oofem and oofeg, without other optional features. I do not know a lot about the other options but i think most users only use those two. I think the testing tool also should be included (with all the example files as well)

I do not have a proposition on whether or not we should include all of the optional features by default. I am afraid the parralel version excludes the normal version so i think it is easier to have different binarys for different flavoures....
Maybe we can have oofem-iml, oofem-dss, poofem-parmetis (parallel oofem with parmetis) binarys?

Greetz, Gerco-Kees

[Václav Šmilauer (eudoxos)]

I uploaded oofem 1.9 package to my ppa: https://launchpad.net/~eudoxos/+archive/ppa/+packages (and hope it will build), for karmic. It needs some packages from my ppa (ckit, elixir, iml++).

It builds oofem, poofem, oofeg and documentation (4 packages: oofem, oofem-mpi, oofem-oofeg, oofem-doc).