code_saturne User's Forum

Hello,

I have written ebuilds for installing C_S-2 beta2 on Gentoo (amd64 arch). These will be submitted to the gentoo science overlay once I have the SYRTHES-3.4.2 ebuild worked out, however I can provide the ebuilds on request.

Regards,

Brennan

Hello Brennan,

This is excellent news! I'm glad to see people wishing to package Code_Saturne.

Have you encounter any trouble in setting up ebuilds? We are about to release a new development version (in a couple of weeks) that will fix some installation issues (notably for MEI library).

I would indeed be interested in having a look at the ebuilds, so that I can suggest modifications if needed. Could you post them here, or send them to Code_Saturne support adress (saturne-support@edf.fr)?

Kind regards,

David

Hello David,

The only problems I remember are related to MPI,  (I think you've since explained some of those on a different post).

The best general distribution point would be from the gentoo repositories, as that's where any updates would go, so I'll post them them to you at the support address. Allow me a few days as the files are at home.

Regards,

Brennan

Gentoo repositories are indeed the best place to distribute Code_Saturne ebuilds!

I'll have a look to the ebuilds when you have time to post them, but no need to hurry for that ;-) And as regards MPI dependency, the blocking issue will be fixed in the next development release.

My apologies for the very late follow-up.

I have updated my build procedure for v2.0.0-rc1 and also the ebuilds, though I've still not dealt with the SYRTHES ebuild.

My build procedure and  gentoo ebuilds derived from that procedure are accessible from http://www.sconegrabber.gen.nz/code_saturne/

The ebuilds have yet to be vetted by gentoo developers, however I have used these ebuilds to install code_saturne across a small cluster employing openMPI.

Hello Brennan,

No worries, this is never too late

First of all, some remarks concerning the configure options listed in the page you linked:
o --disable-mpi-io disables (sic) the use of MPI I/O feature when writing/reading restart files (and post-processing files in a near future). It is provided to tackle with some bugs encoutered with some MPI implementations and for NFS systems without file locking. However, we know provided an option to cs_solver executable to control this feature at runtime and no more at configuration stage (--mpi-io with different options: off, eo, ip IIRC);
o --disable-openmp is the default, no need to provide it to configure script;
o --enable-gui, ditto;
o only mpicc wrapper is needed as Fortran files do not include MPI features (but this is a detail...).

There also something wrong in the pre-requisites definition: Metis version can be 4.0.1 or 5.0-pre2, the number 2.3.4 is rather related to MED.

Now, concerning Code_Saturne ebuilds, I'm far from being a Gentoo expert... sorry! Nonetheless, here are some comments:

o SRC_URI might need some adaptation later on, because 2.0-rc1 version has been posted in this forum because of we currently don't have access to http://www.code-saturne.org  to upload the archives. So this might change in a near future;
o MED version is not required to be greater than 2.3.4, we only require MED >= 2.3 IIRC;
o you explicitly set MPI to OpenMPI in FVM ebuild, contrary to the kernel ebuild where it is set to the virtual package
o CXX need not be set, as we don't have any C++ sources in the code;
o I don't think you need to specify --with-bft in MEI ebuild;
o the correct URI for kernel package download is [url]htthttp://code-saturne.org/forum/old_forums_files/569282765/ncs-200rc1.tgz[/url], slightly different from the other packages (because of the different post);
o you set the minimum version to 2.3.5 for MED (ecs ebuild) compared to 2.3.4 (fvm ebuild), this is not coherent ;
o I would advise you to add --with-mei=/usr (or /usr/local, ...) to ncs ebuild for a proper detection of the Python module of MEI (this "bug" has been detected during Debian packaging).

Finally, I cannot say more to your packaging because I don't know much Gentoo ebuilds... Please, let us know whether these ebuilds go in standard Gentoo repositories, so that we can advertise them.

Good work anyway, and thanks for you interest :)

David

Hello David,

Thanks for your comments, I'll work through them and make the changes necessary.

I'll admit I didn't put much effort into these as the procedures and configuration I used for 2.00 beta2 worked almost immediately for 2.00 rc1. It's possible that there are problems in my installation that I've just not seen broken just because I've not tested beyond my test cases.

I've amended the ebuilds according to your comments, however there are a couple of matters to check.

I'm using MED 2.3.5, yet the configure scripts that check for MED report MED headers >=2.3.4 detected, so I interpreted v2.3.4 as a minimum requirement.

The mei configure script seemed to not detect bft correctly, which is why I added it. And related to that, The user law buttons are usable without specifying the mei path for me. Maybe gentoo and Debian handle python differently.

The ebuilds you saw at the linked site will get updated without any package version comments as they're yet to get into the gentoo development stream. I'll advise here of revisions and eventually their introduction to gentoo package streams, probably into the science overlay.

For the source URIs I have applied manual fetching controls because as you say, the sources are presently only in the forum.

The mpi-io and nfs stuff will have to wait until I am back at work and have access to the cluster.

Regards,

Brennan

Concerning the MED version requirement, you don't need to pay attention to the warning echoed by the configure script. The underlying reason for this warning is that the MED headers changed between the 2.3.1 and 2.3.4 versions, thus we handle MED headers differently depending on MED version.

The minimum version might be 2.3.0 though I'm not sure wheter this version has ever been released. You can link with MED 2.3.1 (available as a Debian package e.g.) without problem, except potential corrections done in later version of MED of course.