[Paraview] Errors when linking catalyst in ParaView version 4.0.1 to simulation code on Titan

Tue Sep 17 10:48:20 EDT 2013

Hong,

Would you mind sharing you CMakeCache (both at the superbuild and paraview
sub build) with me?

I would like to fold your work into ParaViewSuperbuild so that the next
zebra at this watering hole has an easier time of it.

thanks!

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Fri, Sep 6, 2013 at 5:27 PM, Hong Yi <hongyi at renci.org> wrote:

>  Hi Andy, David,
>
> I used GCC to build both ParaView and simulation code. The problem is
> with ParaView's superbuild not being able to find MPI_Fortran on Titan. I
> got the following messages during superbuild:
>
> --------------
> Could NOT find MPI_Fortran (missing:  MPI_Fortran_LIBRARIES
> MPI_Fortran_INCLUDE_PATH)
>
> No FortranCInterface mangling known for coprocessorinitialize
>
> ...
>  --------------
>
> I then tried to add "ftn" into FindMPI.cmake, but got the message "Unable
> to determine MPI from MPI driver /opt/cray/xt-asyncpe/5.17/bin/ftn" prior
> to those MPI_Fortran errors. I looked at ftn wrapper but could not
> determine the mpi Fortran executable, either. Let me know if you have ideas
> on how to make superbuild to find MPI_Fortran.
>
> Many thanks,
>
> Hong
>
>  ------------------------------
> *From:* David E DeMarle [dave.demarle at kitware.com]
> *Sent:* Friday, September 06, 2013 4:21 PM
> *To:* Andy Bauer
> *Cc:* Hong Yi; paraview at paraview.org
>
> *Subject:* Re: [Paraview] Errors when linking catalyst in ParaView
> version 4.0.1 to simulation code on Titan
>
>   The Superbuild on cray uses the backend flavor of the GCC compiler
> (xk7_gcc target). I haven't made an xk7_pgi target yet.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
>
> On Fri, Sep 6, 2013 at 4:07 PM, Andy Bauer <andy.bauer at kitware.com> wrote:
>
>>  Hi Hong,
>>
>>  This Fortran/C mangling issue is a bit tricky. It has to be done during
>> the configuration process because the C and Fortran compilers won't
>> necessarily know how to properly mangle the function names. The thing is
>> that it the configuration process depends on using the same compilers as
>> any other code that links to the generated libraries. You can check out
>> Bill Hoffman's blog at http://www.kitware.com/blog/home/post/231 which
>> explains this issue and how CMake handles it. Now if ParaView Catalyst was
>> built with GCC and you built your simulation code with PGI, for example,
>> then it wouldn't surprise me that this issue crops up. What compilers did
>> you use for your ParaView build and your simulation code build? If they are
>> consistent then it is a problem with CMake or ParaView's superbuild.
>>
>>  Regards,
>> Andy
>>
>>
>> On Fri, Sep 6, 2013 at 3:54 PM, Hong Yi <hongyi at renci.org> wrote:
>>
>>>  Hi Andy,****
>>>
>>> ** **
>>>
>>> Thanks for the useful info. You are exactly right – the problem is
>>> caused by C/Fortran mangling of the names. In the Fortran code, underbar
>>> trailing is not there for all catalyst-related function calls, those
>>> underbar trailing to the function names as shown in the linking errors are
>>> automatically added by C/Fortran mangling in the final linking stage. I
>>> also pulled in the Fortran example in the github repo, and got the similar
>>> undefined reference errors in the final linking stage when linking to the
>>> ParaView 4.0 built with superbuild. So the linking problem seems to be
>>> generic to Fortran code linking to Catalyst. ****
>>>
>>> ** **
>>>
>>> I checked the Catalyst static lib built with superbuild and found the
>>> lib only includes function symbols without the trailing underbar such as
>>> coprocessorinitialize, which explains why those undefined reference errors
>>> result. I also tried to build ParaView 3.98 with superbuild which included
>>> FortranAdaptor lib, and found the FortranAdatpor lib built with superbuild
>>> does not include the trailing underbar for coprocessor-related functions,
>>> while the FortranAdaptor lib built from source does include the trailing
>>> underbar, which explains why I can link our simulation code to Catalyst
>>> 3.98 built from source, but cannot successfully link to Catalyst 3.98 built
>>> with superbuild. So here is my question:****
>>>
>>> ** **
>>>
>>> Should Catalyst libs built with superbuild contain those coprocessing
>>> function symbols with trailing underbar in addition to those corresponding
>>> function symbols without trailing underbar? Specifically, for example, I am
>>> wondering whether both coprocessorinitialize and coprocessorinitialize_
>>> need to present so these coprocessing functions can be called from
>>> different languages including Fortran? Could you confirm whether this is
>>> the case? If so, I need to check my superbuild to see why those trailing
>>> underbar functions are not created in the Catalyst libs. Let me know if
>>> you, David, or anybody else can confirm whether this is the case, or offer
>>> any ideas/suggestions.****
>>>
>>> ** **
>>>
>>> Thanks,****
>>>
>>> ** **
>>>
>>> Hong****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Andy Bauer [mailto:andy.bauer at kitware.com]
>>> *Sent:* Friday, September 06, 2013 12:33 PM
>>> *To:* Hong Yi
>>> *Cc:* paraview at paraview.org
>>> *Subject:* Re: [Paraview] Errors when linking catalyst in ParaView
>>> version 4.0.1 to simulation code on Titan****
>>>
>>> ** **
>>>
>>> Hi Hong,****
>>>
>>> ** **
>>>
>>> I think it's the Fortran mangling of the names. Try taking out the
>>> underscore on the Fortran subroutine calls. Let me know if that doesn't
>>> help. Otherwise it may be an issue with how C/Fortran mangles things. The
>>> GCC behavior should be the following:****
>>>
>>> Fortran -> call xyz()****
>>>
>>> C -> void xyz_() {...}.****
>>>
>>> All of these methods should be available in the vtkPVCatalyst module. If
>>> you can't get it to work, try to see what you can do with the Fortran
>>> example in the github repo.****
>>>
>>> ** **
>>>
>>> Regards,
>>> And****
>>>
>>> ** **
>>>
>>> On Thu, Sep 5, 2013 at 5:52 PM, Hong Yi <hongyi at renci.org> wrote:****
>>>
>>> When linking our simulation code (a variant of phasta) to Catalyst in
>>> ParaView version 4.0.1 built on Titan with superbuild, I got the following
>>> linking errors:
>>>
>>> -----------------
>>> ../../lib/libincompressible.a(itrdrv.f.o): In function `itrdrv_':
>>> itrdrv.f:(.text+0x2add): undefined reference to `coprocessorinitialize_'
>>> itrdrv.f:(.text+0x6198): undefined reference to `coprocessorfinalize_'
>>> itrdrv.f:(.text+0x973d): undefined reference to `coprocessorfinalize_'
>>> ../../lib/libincompressible.a(phastaadaptor.f.o): In function
>>> `phastacoprocessor_':
>>> phastaadaptor.f:(.text+0x84): undefined reference to
>>> `requestdatadescription_'
>>> phastaadaptor.f:(.text+0x95): undefined reference to `needtocreategrid_'
>>> phastaadaptor.f:(.text+0xba): undefined reference to `coprocess_'
>>> /usr/bin/ld: link errors found, deleting executable
>>> `../../bin/phastaIC.exe'
>>> -----------------
>>>
>>> I use CMake to link Catalyst to our simulation code. I was able to
>>> resolve those linking errors when linking to ParaView version 3.98.1 by
>>> adding "find_package(ParaView 3.98 REQUIRED COMPONENTS FortranAdaptor)" in
>>> addition to find_package for vtkCoProcessorImplementation and then link
>>> both to the final executable. However, for ParaView version 4.0.1, it seems
>>> FortranAdaptor does not exist any more which defines those functions such
>>> as coprocessorinitialize, etc. Here is the corresponding excerpt in my
>>> CMakeLists.txt related to linking Catalyst in ParaView version 4.0.1:
>>> -------------------
>>> if(USE_CATALYST)
>>>        find_package(ParaView 3.98 REQUIRED COMPONENTS
>>> vtkPVPythonCatalyst)
>>>         find_library(PHASTA_ADAPTOR_LIB PhastaAdaptorLib)
>>>         include("${PARAVIEW_USE_FILE}")
>>>         set(Adaptor_SRCS phastaadaptor.f)
>>>         add_library(Adaptor ${Adaptor_SRCS})
>>>         target_link_libraries(Adaptor ${PHASTA_ADAPTOR_LIB}
>>> vtkPVPythonCatalyst)
>>>         add_definitions("-DUSE_CATALYST")
>>> endif()
>>> -------------------
>>>
>>> Adaptor is then linked to the final executable.
>>>
>>> Please let me know if you have ideas on what I should do to resolve
>>> those linking errors.
>>>
>>> Many thanks,
>>>
>>> Hong
>>>
>>>
>>> ****
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the ParaView Wiki at:
>>> http://paraview.org/Wiki/ParaView
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.paraview.org/mailman/listinfo/paraview****
>>>
>>> ** **
>>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ParaView Wiki at:
>> http://paraview.org/Wiki/ParaView
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.paraview.org/mailman/listinfo/paraview
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20130917/55033a6e/attachment.htm>