more information about catalyst_status_error_not_found

I am trying to port my application to a different platform but when I run it the error code is returning as 3 from catalyst initialization routine.

200: catalyst debug: search path from default list: `/work2/noaa/nems/tufuk/COP/spack-stack-1.9.1/envs/cop/install/oneapi/2024.2.1/libcatalyst-2.0.0-xhbiy3w/lib64/catalyst`
200: catalyst debug: trying to load `/work2/noaa/nems/tufuk/COP/spack-stack-1.9.1/envs/cop/install/oneapi/2024.2.1/libcatalyst-2.0.0-xhbiy3w/lib64/catalyst/libcatalyst-paraview.so`: invalid

It seems that 3 means catalyst_status_error_not_found but I could not find more information about the error message. I double check by setting export CATALYST_DEBUG=1 in my job and confirmed that libcatalyst-paraview.so is in the correct path. I wonder if you have any suggestion to debug the issue? I also tried to set export PARAVIEW_LOG_CATALYST_VERBOSITY="INFO" but I think the code is not reaching to ParaView level. So, I am not getting any more information.

Just to update if I set export CATALYST_IMPLEMENTATION_NAME="stub" then it picks the stub implementation under catalyst installation and works. But, if I set to paraview then it tries to get it from paraview installation directory and does not accept it by saying invalid. I am not sure what is looking for to sat valid or invalid at this point. I installed all packages with same compiler etc.

I also set export CATALYST_IMPLEMENTATION_NAME=“vtk” and it picked the shared library from paraview installation and passed the initialization without any error.

invalid means that dlopen gave us an invalid handle. I’ll look at providing more information in the debug from libcatalyst.

ParaView isn’t even being loaded, so it has no chance to do anything about it.

See this MR to provide more information: https://gitlab.kitware.com/paraview/catalyst/-/merge_requests/127

Hey,

Sorry if this is an obvious answer. Did you confirm that your ParaView has Catalyst? You should be able to see the libcatalyst-paraview.so in $PARAVIEW_ROOT/lib/catalyst/. It’s weird that you can pickup the vtk implementation but not the ParaView one. Also, try setting $CATALYST_IMPLEMENTATION_PATH (I’m typing from memory, so double check the actual spelling).

@ben.boeckel Thanks for help. I think #127 is not merged yet. Right? Maybe I could give a try when it is available to get more information.

@Alexandre_Minot libcatalyst-paraview.so is in my installation directory but somehow the code does not pick it up and says invalid. I also tried by setting CATALYST_IMPLEMENTATION_PATHS (I was adding it to the node before) and it did not help. So, probably the issue is in somewhere else.

@ben.boeckel It seems it is merged. Let me try with master again,

@ben.boeckel Okay. I run it in my end with catalyst master. Here is the output. The extra information is returning no error which seems strange. I also confirmed that the file is in the indicated location. Any idea?

200: catalyst debug: trying to load `/work2/noaa/nems/tufuk/COP/spack-stack-1.9.1/envs/cop/install/oneapi/2024.2.1/paraview-5.13.1-uwaer47/lib64/catalyst/libcatalyst-paraview.so`: invalid ((no error))
200: catalyst debug: search path from default list: `/work2/noaa/nems/tufuk/COP/spack-stack-1.9.1/envs/cop/install/oneapi/2024.2.1/libcatalyst-master-jvhtiov/lib64/catalyst`
200: catalyst debug: trying to load `/work2/noaa/nems/tufuk/COP/spack-stack-1.9.1/envs/cop/install/oneapi/2024.2.1/libcatalyst-master-jvhtiov/lib64/catalyst/libcatalyst-paraview.so`: invalid ((no error))

BTW, I have no libcatalyst-paraview.so under libcatalyst-master-jvhtiov but I think since it is not accepting the one in paraview installation directory, it automatically tries to find the one from catalyst directory. So, it should be fine.

@ben.boeckel Maybe it is not entering to following if statement, https://gitlab.kitware.com/paraview/catalyst/-/merge_requests/127/diffs?file=4f83c53e5748fd50a8607afea8f59ef9c52e5085#4f83c53e5748fd50a8607afea8f59ef9c52e5085_356_356 I wonder if I need to install catalyst in debug mode. Maybe setting export CATALYST_DEBUG=1 is not enough.

/work2/noaa/nems/tufuk/COP/spack-stack-1.9.1/envs/cop/install/oneapi/2024.2.1/libcatalyst-master-jvhtiov/lib64/catalyst/libcatalyst-paraview.so

Note how it’s looking for paraview catalyst in the catalyst stub folder instead of in the paraview folder. I see this when the ParaView environment is not set correctly. Just to be safe, I would triple check your environment. Make sure that your LD_LIBRARY_PATH has $PARAVIEW_ROOT/lib64.

I hope this helps

Actually, never mind, it looked for Catalyst in your ParaView folder first then fell back to looking in the stub. No idea what’s up, sorry.

@Alexandre_Minot Thanks for your suggestion. In any case, I could try again by setting LD_LIBRARY_PATH in my job submission script to test it.

No setting LD_LIBRARY_PATH did not help.

Does LD_DEBUG=libs in the environment help? That causes dlopen to trigger logging of what’s going on inside of it.

@ben.boeckel Okay. It produces lots of output. Is there anything that I need to look at. The last thing before trying to load libcatalyst-paraview.so is the EGL libraries.

@ben.boeckel I am seeing following in the log - (RPATH from file /work2/noaa/nems/tufuk/COP/spack-stack-1.9.1/envs/cop/install/oneapi/2024.2.1/paraview-5.13.1-uwaer47/lib64/catalyst/libcatalyst-paraview.so). Maybe there is something wrong with this and it create confusion. Not sure.

There’s no mention of the path of interest beyond the RPATH thing? Usually an error is mentioned somewhere…unless something fundamentally makes the library ineligible. Is it the right architecture?

Before 200: catalyst debug: trying to load /work2/noaa/nems/tufuk/COP/spack-stack-1.9.1/envs/cop/install/oneapi/2024.2.1/paraview-5.13.1-uwaer47/lib64/catalyst/libcatalyst-paraview.so: invalid ((no error)) log output, I have only log related with RPATH. I don’t think it is an architecture issue since vtk is working fine which is shipped with same ParaView installation but let me check more carefully.

I could run same setup in terms of installation and simulation case with different platform using GPU nodes and EGL setup successfully. It uses same compiler but different MPI implementation. So, maybe I could compare the differences to find out the issue.