Submission: sundials

[jjstickel (Jonathan Stickel)]

New port for sundials, a SUite of Nonlinear and DIfferential/ALgebraic equation Solvers. Portfile attached.

[jjstickel (Jonathan Stickel)]

This is a dependent for py-assimulo, ticket #35363.

[jjstickel (Jonathan Stickel)]

I attempted to build with shared libraries, but "make install" does not use DESTDIR, and using "prefix=${destroot}${prefix}" instead (as it is in the Portfile) improperly designates the rpath of the shared libraries. I have some ideas about a fix to communicate upstream, but I do not have the time at the moment. The static libraries seem to work just fine.

[jjstickel (Jonathan Stickel)]

Created a source patch and modified the portfile to enable shared libraries.

[dershow]

Cc Me!

[larryv (Lawrence Velázquez)]

Has duplicate #39338.

[dershow]

Has there been any progress on this? I just built a basic port, to install SUNDIALS, and then was pointed to this ticket. It appears that this ticket has already solved the problem that I ran into. I would also like to suggest the following addition to the portfile:

variant g95 {
    configure.args-append   F77=${prefix}/bin/g95
    depends_lib-append      port:g95
}

It appears that this port was just never accepted for some reason?

[cooljeanius (Eric Gallager)]

Cc Me!

[jjstickel (Jonathan Stickel)]

Replying to dersh@…:

Has there been any progress on this? I just built a basic port, to install SUNDIALS, and then was pointed to this ticket. It appears that this ticket has already solved the problem that I ran into.

...

It appears that this port was just never accepted for some reason?

Adding a g95 variant should be fine. Feel free to modify the portfile attached to the ticket and reattach it as a new improved file.

These low-demand portfile additions tend to be low priority to developers. Maybe this bit of chatter here will motivate someone to commit it.

[dershow]

g95 variant added

[dershow]

Added that variant, and uploaded it (it would not let me replace the existing file). I hope this will help get it committed.

[mf2k (Frank Schima)]

Since this is a new port, please remove the gcc43 and gcc44 variants and add gcc48 and gcc49 instead. Let's look forward, not backwards.

Note: Removed silly comment about g95 variant.

[cooljeanius (Eric Gallager)]

Since this is a new port, please remove the gcc43 and gcc44 variants and add gcc48 and gcc49 instead. Let's look forward, not backwards.

Why not have both the old and new variants? Can't we look both forwards and backwards?

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Why not have both the old and new variants? Can't we look both forwards and backwards?

We should not be encouraging the use of ancient compilers that, as of today, have been obsoleted four and five times over.

[jjstickel (Jonathan Stickel)]

Updated the portfile with gcc43 and 44 removed and gcc48 and 49 added. I also changed the default to be gcc47 (rather than gcc45).

I also added a comment that for the examples variant, it seems that the examples are compiled but then not installed. Someone interested could check on this -- I don't have time at the moment.

[dershow]

I am curious if there is a reason to require a version of gcc? When I tried to just build this package, before I found this port, it seemed to build fine with just default settings, which would have used clang I believe.

[jjstickel (Jonathan Stickel)]

Updated the portfile again to add a description for the g95 variant.

[mf2k (Frank Schima)]

Looking at the Portfile, there are a number of minor issues - including the g95 description which you just fixed. The main one I see is that the default variants are confusing. I put them all together, so take a look and see if this is what you intended? Note that I append other default variants instead of overwriting as originally written in the Portfile.

default_variants +atlas
if { ![variant_isset gcc42] && ![variant_isset gcc48] && ![variant_isset gcc49] && ![variant_isset gcc46] && ![variant_isset gcc47] } {
	default_variants-append +gcc47
}
if {![variant_isset mpich2]} {
    default_variants-append +openmpi
}

[mf2k (Frank Schima)]

Replying to dersh@…:

I am curious if there is a reason to require a version of gcc? When I tried to just build this package, before I found this port, it seemed to build fine with just default settings, which would have used clang I believe.

Usually this is to compile FORTRAN code for better performance, but the variants descriptions do not say this.

[jjstickel (Jonathan Stickel)]

Replying to macsforever2000@…:

default_variants +atlas
if { ![variant_isset gcc42] && ![variant_isset gcc48] && ![variant_isset gcc49] && ![variant_isset gcc46] && ![variant_isset gcc47] } {
	default_variants-append +gcc47
}
if {![variant_isset mpich2]} {
    default_variants-append +openmpi
}

This looks fine, although there was a typo where the "gcc42" should be "gcc45" (I had also fixed this in the latest upload).

[mf2k (Frank Schima)]

Now I'm seeing this error:

--->  Attempting to fetch sundials-2.5.0.tar.gz from http://www.llnl.gov/casc/sundials/download/code/
--->  Verifying checksums for sundials
Error: No checksum set for sundials-2.5.0_destdir.patch
Error: No checksum set for sundials-2.5.0.tar.gz
Error: org.macports.checksum for port sundials returned: Unable to verify file checksums

Also, what is the intention of the +doc variant? Why are you using system "cp -r...", seems like you should be using xinstall?

[mf2k (Frank Schima)]

Also, I was wrong about using default_variants-append, apparently the way you had it written is correct.

[jjstickel (Jonathan Stickel)]

Replying to macsforever2000@…:

Now I'm seeing this error:

--->  Attempting to fetch sundials-2.5.0.tar.gz from http://www.llnl.gov/casc/sundials/download/code/
--->  Verifying checksums for sundials
Error: No checksum set for sundials-2.5.0_destdir.patch
Error: No checksum set for sundials-2.5.0.tar.gz
Error: org.macports.checksum for port sundials returned: Unable to verify file checksums

I just installed sundials via the attached Portfile, including a new fetch, without trouble. I am not sure why you have this error.

Also, what is the intention of the +doc variant? Why are you using system "cp -r...", seems like you should be using xinstall?

There are several pdfs in a few subdirectories, and I found that cp -r was the simplest way of copying them over. I was not able to make xinstall do what I wanted. If you know of an equivalent one-liner using xinstall, I would be interested to see it.

[jjstickel (Jonathan Stickel)]

shared libraries enabled

[jjstickel (Jonathan Stickel)]

I added "static" and "debug" variants. I found these helpful when trying to debug some code of mine that uses sundials.

Would a developer please take a look at this again, please?

[seanfarley (Sean Farley)]

Replying to jjstickel@…:

I added "static" and "debug" variants. I found these helpful when trying to debug some code of mine that uses sundials.

Would a developer please take a look at this again, please?

I'd really like to discuss this port after deciding on the mpi and compiler port groups: ​https://lists.macosforge.org/pipermail/macports-dev/2013-July/023410.html

But here are a few quick notes on your portfile:

• you don't need the destdir patch if you build with cmake
• you'll probably to fix the use of install_name_dir (you can check this by using 'otool -L /opt/local/lib/*sundial*.dylib
• you no longer need the depends_lib for the compilers
• your g95 variant will certainly give you problems with your mpich and openmpi variants since neither of those ports have a g95 variant
• you really don't need a static variant, imo; sundials will install the static libraries along side the shared ones
• (other devs take note) can we please not set the atlas variant as default on ports that are designed for sparse linear algebra?

[jjstickel (Jonathan Stickel)]

Replying to sean@…:

I'd really like to discuss this port after deciding on the mpi and compiler port groups: ​https://lists.macosforge.org/pipermail/macports-dev/2013-July/023410.html

That discussion is beyond me. I hope that this port can be committed and then adjusted appropriately based whatever is decided for mpi.

But here are a few quick notes on your portfile:

• you don't need the destdir patch if you build with cmake

OK, but I can't seem to make sundials compile shared libraries with cmake, and it seems that the developers of Sundials consider cmake to be a secondary build system (see INSTALL_NOTES from the Sundials sources).

• you'll probably to fix the use of install_name_dir (you can check this by using 'otool -L /opt/local/lib/*sundial*.dylib

Not sure what you mean here -- is this in reference to using cmake for building?

• you no longer need the depends_lib for the compilers

I presume that you mean the depends_lib-append may be changed to depends_build-append for the compilers?

• your g95 variant will certainly give you problems with your mpich and openmpi variants since neither of those ports have a g95 variant

It looks like openmpi has a g95 variant, but mpich does not. I can add a conflict for g95 to +mpich, if you think that is sufficient.

• you really don't need a static variant, imo; sundials will install the static libraries along side the shared ones

I can easily remove this variant.

• (other devs take note) can we please not set the atlas variant as default on ports that are designed for sparse linear algebra?

I don't follow, but I can remove this default variant.

I will upload an edited Portfile after I see some response to my questions/comments above. Thanks.

[seanfarley (Sean Farley)]

Replying to jjstickel@…:

That discussion is beyond me. I hope that this port can be committed and then adjusted appropriately based whatever is decided for mpi.

Sure, but it makes a simple portfile. Though I'm not opposed to adding sundials before that decision.

• you don't need the destdir patch if you build with cmake

OK, but I can't seem to make sundials compile shared libraries with cmake, and it seems that the developers of Sundials consider cmake to be a secondary build system (see INSTALL_NOTES from the Sundials sources).

Yes, Carol hasn't given cmake much love but it does indeed work.

• you'll probably to fix the use of install_name_dir (you can check this by using 'otool -L /opt/local/lib/*sundial*.dylib

Not sure what you mean here -- is this in reference to using cmake for building?

Yep. You can see my version of the portfile ​here.

• you no longer need the depends_lib for the compilers

I presume that you mean the depends_lib-append may be changed to depends_build-append for the compilers?

Actually, you can get rid of the line altogether since MacPorts 2.2 handles it in base.

• your g95 variant will certainly give you problems with your mpich and openmpi variants since neither of those ports have a g95 variant

It looks like openmpi has a g95 variant, but mpich does not. I can add a conflict for g95 to +mpich, if you think that is sufficient.

I would say just get rid of it entirely unless you really need an interface built with g95?

• you really don't need a static variant, imo; sundials will install the static libraries along side the shared ones

I can easily remove this variant.

Yeah, it simplifies things greatly.

• (other devs take note) can we please not set the atlas variant as default on ports that are designed for sparse linear algebra?

I don't follow, but I can remove this default variant.

Sundials is a suite of time-stepping methods (well, just two, really: Adams-Moulton and BDF) with a default JFNK (Jacobian Free Newton-Krylov) iterative method. You can use a dense (direct) solver for a single processor but using that for multiple processors is unsupported since the bulk of Sundials users are in the sparse matrix world (aka, iterative methods). ATLAS is an automatically tuned, dense linear algebra package. Hence, you will see practically no speed up by linking Sundials with ATLAS. Hence, I am opposed to having it be the default variant. I don't even think it should be a variant at all but I could be convinced otherwise.

[jjstickel (Jonathan Stickel)]

Replying to sean@…:

Replying to jjstickel@…:

Not sure what you mean here -- is this in reference to using cmake for building?

Yep. You can see my version of the portfile ​here.

I had a little time to try out your cmake-based portfile (I also added your "compilers" and "mpi" portgroups to my local tree). It works OK if all you want are the C libraries. However, I can't get the Fortran libraries to compile. I modified your portfile (see attached). When using the +gcc47 variant (turns on FCMIX), I get:

cd /opt/local/var/macports/build/_Users_Shared_install_macports_ports_math_sundials/sundials/work/sundials-2.5.0/build/src/nvec_ser && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/sundials_fnvecserial_static.dir/link.txt --verbose=1
/opt/local/bin/ar cr libsundials_fnvecserial.a  CMakeFiles/sundials_fnvecserial_static.dir/fnvector_serial.o
Undefined symbols for architecture x86_64:
  "_N_VCloneVectorArrayEmpty_Serial", referenced from:
      _fnvinits_s_ in fnvector_serial.o
  "_N_VNewEmpty_Serial", referenced from:
      _fnvinits_ in fnvector_serial.o
      _fnvinits_q_ in fnvector_serial.o
      _fnvinits_b_ in fnvector_serial.o
      _fnvinits_qb_ in fnvector_serial.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [src/nvec_ser/libsundials_fnvecserial.0.0.2.dylib] Error 1

I don't get these errors and have functional Fortran Sundials libraries if I build via autotools.

[martin@…]

Cc Me!

[cooljeanius (Eric Gallager)]

r116384 should close this

[martin@…]

This is not working since the Portfile broke a few days ago when the SSL certificate on the master expired and some domain names moved around. The package is not on the mirrors either.

Some lines from the log:

:notice:fetch --->  Attempting to fetch sundials-2.5.0.tar.gz from http://www.llnl.gov/casc/sundials/download/code/
:debug:fetch Fetching distfile failed: SSL certificate problem: Invalid certificate chain
:notice:fetch --->  Attempting to fetch sundials-2.5.0.tar.gz from http://distfiles.macports.org/sundials
:debug:fetch Fetching distfile failed: The requested URL returned error: 404 Not Found

The correct download link for http is now: ​http://computation.llnl.gov/casc/sundials/download/code/sundials-2.5.0.tar.gz The used URL ​http://www.llnl.gov/casc/sundials/download/code/sundials-2.5.0.tar.gz redirects to https with a broken certificate.

[jjstickel (Jonathan Stickel)]

When installing via the committed Portfile, I get:

$ sudo port -u install sundials +atlas +gcc47
dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid
--->  Computing dependencies for sundials
--->  Dependencies to be installed: mpich
--->  Fetching distfiles for mpich
--->  Verifying checksums for mpich
--->  Extracting mpich
--->  Configuring mpich
Error: mpich has been made obsolete by the port mpich-default. Please install mpich-default instead.
Error: org.macports.configure for port mpich returned: obsolete port
Error: Failed to install mpich
Please see the log file for port mpich for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_leatherman.nrel.gov_macports_release_tarballs_current_ports_science_mpich/mpich/main.log
Error: The following dependencies were not installed: mpich
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port sundials failed

Even after I install mpich-default, I still get the above. Not sure if this is a bug with this Portfile or with all the mpi stuff.

[cooljeanius (Eric Gallager)]

Replying to jjstickel@…:

Not sure if this is a bug with this Portfile or with all the mpi stuff.

Might want to cc sean on this seeing as he was the one doing all the mpi stuff...

[jjstickel (Jonathan Stickel)]

Replying to egall@…:

Replying to jjstickel@…:

Not sure if this is a bug with this Portfile or with all the mpi stuff.

Might want to cc sean on this seeing as he was the one doing all the mpi stuff...

I can't add him as a cc on this ticket, but I will email him separately. Perhaps a developer should make this ticket "owned by" Sean. After all, the committed Portfile lists Sean as the maintainer.

[seanfarley (Sean Farley)]

Replying to jjstickel@…:

Replying to egall@…:

Replying to jjstickel@…:

Not sure if this is a bug with this Portfile or with all the mpi stuff.

Might want to cc sean on this seeing as he was the one doing all the mpi stuff...

I can't add him as a cc on this ticket, but I will email him separately. Perhaps a developer should make this ticket "owned by" Sean. After all, the committed Portfile lists Sean as the maintainer.

Thanks for cc'ing me. I get all ticket updates, fyi, since I'm subscribed to the ticket list. I'm looking into the issue now. Could you post the log file (port log sundials) too?

[jjstickel (Jonathan Stickel)]

sundials log with mpich error

[jjstickel (Jonathan Stickel)]

OK, added the logfile for sundials.

[seanfarley (Sean Farley)]

Replying to jjstickel@…:

OK, added the logfile for sundials.

Hmmm, do you have happen to have an old version of my mpi portgroup installed?

[jjstickel (Jonathan Stickel)]

Oops! Sorry, yes I did. I got things working now, although I don't understand why both mpich-default+gcc47 AND mpich-gcc47+fortran were installed.

Not sure if it was an oversight or by purpose, but you left out installation of the LICENSE and README files, and also the 'doc' variant. I will add a patch for these. Finally, this patch also includes the new download link mentioned above.

[seanfarley (Sean Farley)]

Replying to jjstickel@…:

Oops! Sorry, yes I did. I got things working now, although I don't understand why both mpich-default+gcc47 AND mpich-gcc47+fortran were installed.

The difference between the two is with the C compiler:

mpich-default+gcc47 = clang C compilers and gcc47 for fortran
mpich-gcc47+fortran = gcc for every compiler
mpich-gcc47         = gcc for C compilers and no fortran

This is a left over artifact from the previous version. I'm unsure if I want to do the work of removing it, so I'll wait to hear back from eborisch.

Not sure if it was an oversight or by purpose, but you left out installation of the LICENSE and README files, and also the 'doc' variant. I will add a patch for these. Finally, this patch also includes the new download link mentioned above.

Awesome, thanks for the patch. I'm trying to put out a few other fires and will commit this after looking at OpenMPI.

[seanfarley (Sean Farley)]

Ok, patched in r116425, r116426, r116427. Closing this ticket now. If something else is wrong, then let's start a new ticket.