[Release] Linker problems with AGMG about opm-core HOT 18 CLOSED

that the symbol seems to be in libopmcore.a

That is probably only the import entry; you can verify this with:

objdump  -R  lib/libopmcore.a  |  grep dagmg_mumps

from opm-core.

Unable to reproduce; maybe it is related to the version of AGMG used.

from opm-core.

On Mon, Mar 18, 2013 at 02:59:07AM -0700, @rolk wrote:

That is probably only the import entry; you can verify this with:

objdump  -R  lib/libopmcore.a  |  grep dagmg_mumps

outputs:

objdump: BlackoilPvtProperties.cpp.o: not a dynamic object
objdump: BlackoilPvtProperties.cpp.o: Invalid operation

---

Reply to this email directly or view it on GitHub:
#206 (comment)

Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany, USt-Id: DE279960836
Tel.: +49 (0) 160 97590858 Fax: +49 (0)322 1108991658

Please notice the new address!

from opm-core.

objdump  -R  lib/libopmcore.a  |  grep dagmg_mumps

outputs:

objdump: BlackoilPvtProperties.cpp.o: not a dynamic object
objdump: BlackoilPvtProperties.cpp.o: Invalid operation

What about

nm lib/libopmcore.a | grep dagmg_mumps

?

from opm-core.

@blattms Please try if the patch at rolk/opm-core:206_mumps solves the issue.

(There is however another problem with that: If I include that patch is my build, it fails on compiling dagmg_mumps.f90 -- apparently this module isn't 64-bit safe)

from opm-core.

On Mon, Mar 18, 2013 at 03:04:55AM -0700, Roland Kaufmann wrote:

Unable to reproduce; maybe it is related to the version of AGMG used.

It is version 3.1.2.

It seems like dgamg_mumps.f90 is not built on my system:

ls ./CMakeFiles/opmcore.dir/home/mblatt/src/3rdParty/AGMG_3.1.2/SRC/
dagmg.f90.o  dagmg.f90.o.provides.build

from opm-core.

It seems like dgamg_mumps.f90 is not built on my system

As said: rolk/opm-core:206_mumps should fix that. It will need a version of AGMG >= 3.1, but I'm inclined put that as a requirement, and put it in if that patch works.

from opm-core.

On Mon, Mar 18, 2013 at 03:34:51AM -0700, Roland Kaufmann wrote:

As said: rolk/opm-core:206_mumps should fix that. It will need a version of AGMG >= 3.1, but I'm inclined put that as a requirement, and put it in if that patch works.

That worked with a clean AGMG src directory (otherwise some old *.mod
files get reused) and an old compiler (GNU 4.4). (Apparently AGMG
cannot be compiled with gfortran-4.7).

from opm-core.

Apparently AGMG cannot be compiled with gfortran-4.7

That's right. Well, maybe the actual AGMG sources can be built with a recent compiler (I haven't tried), but the MUMPS support library definitely can not. I've only been able to use GFortran <= 4.4. This is one of the reasons why I don't generally recommend AGMG. The solver is fine when it works, but building it yourself is a sobering experience.

from opm-core.

the MUMPS support library definitely can not

Is it a feasible approach to use system-provided mumps libraries (libmumps-dev on Debian), and remove the agmg prefix in front of the mumps calls inside main AGMG?

from opm-core.

On Mon, Mar 18, 2013 at 03:10:50PM -0700, Roland Kaufmann wrote:

the MUMPS support library definitely can not

Is it a feasible approach to use system-provided mumps libraries
(libmumps-dev on Debian), and remove the agmg prefix in front of
the mumps calls inside main AGMG?

Sounds like a lot of maintainance work for OPM, which should normally
be done upstream.

from opm-core.

There has been no PR for this issue, should we merge before release with your '206_*' branch, @rolk?

from opm-core.

should we merge before release with your '206_*' branch, @rolk?

I am not quite sure. To me it seems that not using the mumps part you may be able to get a sequential version going, whatever that is worth. With it, the build will probably break when using a newer toolchain. Neither is particulary good options. Someone more familiar with AGMG than me may be able to give better advise.

from opm-core.

I'll assign this to the next release then, unless there are lots of protesting.

from opm-core.

maybe the actual AGMG sources can be built with a recent compiler (I haven't tried), but the MUMPS support library definitely can not

Is it a feasible approach to use system-provided mumps libraries (libmumps-dev on Debian), and remove the agmg prefix in front of the mumps calls inside main AGMG?

Sounds like a lot of maintainance work for OPM, which should normally be done upstream.

How about providing a dummy dagmg_mumps.f90 which only contain declarations of the subroutines, and then call the ones wthout the agmg prefix (i.e. the system ones). Then we include dagmg.f90 and the dummy in our project and link with system mumps?

from opm-core.

How about wrapping the system MUMPS library in a dummy dagmg_mumps.f90 module whereby AGMG's prerequisites can be satisfied?

That's actually a very good idea. At least in theory. I don't know how much work it would be to actually execute this plan in practice though. Having (briefly) reviewed the AGMG source, the MUMPS library calls appear to be rather tightly coupled to the AGMG structure. At the very least we will need to study the AGMG code rather more thoroughly than I've done until now.

Does anyone have the time (and inclination) to come up with an overview of the extent of required work?

from opm-core.

May be fixed in #308; please re-test.

from opm-core.

Rendered irrelevant by #308 and #314

from opm-core.