I installed preCICE on my local client to couple solver dummy with a different CFD solver. After going through the entire process the two solvers were successfully coupled. However, now I am trying to carry out the same coupling on a remote server. For this, I copied my entire solver code to the new server which includes the fortran solver binding folder also. I also copied the solver dummy folder to the sever. I installed preCICE on the remote server. I complied the solverdummy using the aforementioned fortran-solver module. I was able to build the second solver with the new linker location setting and solver module location embedded.
Although, now when I try run the two solvers for coupling on this server, using the same commands which were able to run the two solvers on the local client, I am getting the same error as provided below:
terminate called after throwing an instance of ‘std::__ios_failure’
what(): basic_filebuf::underflow error reading the file: Is a directory
Program received signal SIGABRT: Process abort signal.
I would request you to please guide me on why this error is coming again and again for both the solvers.
The previous problem mentioned in the mail had been solved.
However, when I am trying to couple my FORTRAN based CFD solver with PALM solver. The solver seems to run for some initial 100-300 iterations, but after a while the simulations suddenly stop without any error being displayed by either solver. After bebugging it seems that one of the ranks gets stuck at the advance(dt) step. I also noticed that precice-profiling file is not generated by PALM, whereas it is present for the second CFD solver. Notably, the same solver was running well with the dummy solver earlier.
Can you guide me on what could be the reason for such a stoppage?
Your help in this regards is highly appreciated.
@Manish what was the cause of the original problem?
Please make a new thread for each different issue that can be marked as “solved”, to help us keep an overview. In fact, you can choose which post contains the answer, to help others landing on the thread with similar issues.
When one participant is waiting, the issue is typically with the other one. Some logs would be helpful.
One cause could be that the end time is not configured/followed correctly by the other solver. Maybe it exits before the coupling is completed. Also, if only one rank holds the coupling interface, then waiting for the other participant would be explained.
With regards to the previous problem, I could not check it again exactly for the batch mode calculations. However, a similar problem occurred while carrying out the coupling on my local system, which was resolved using the correct configuration file directory. I thank you for your suggestion earlier.
I have also duly noted your suggestion to start a new thread for every problem.
Based on your previous suggestion on the current problem I have tried to use the log settings. Due to that, I know that the computation on one of the ranks stops at the precicef_advance(dt) stage. I am also including the snippet of log files related to both the solvers.
Also could you tell me why the precicef_profiling directory is not generated for PALM, whereas it is there for the other solver. Could it be related to the sudden stoppage issue?
Context: PALM simulations run in single core and run very fast, due to which it ends very early and also seems to be closing the connection. The second solver performs more comprehensive calculations and proceeds at its own slow speed beyond PALM;s termination and stops after a while.
I am trying to couple PALM (an atmospheric fluid solver) with an inhouse CFD solver on a remote server. All the installations and linkages have been carried out successfully.
When I call atmospheric model using the prescribed command, it waits for communication from the other CFD solver and shows the following on terminal: PALM: Writing initial data preCICE: Setting up primary communication to coupling partner/s
However, when I run the relevant mpirun command for my coupled CFD solver, it returns the following error:
mpirun -np 4 /scratch/ws/ws1/iagtripa-meridonal_m/CFDReboot/build/bin/CFDSolver > std.out
terminate called after throwing an instance of 'std::__ios_failure'
what(): basic_filebuf::underflow error reading the file: Is a directory
Program received signal SIGABRT: Process abort signal.
Backtrace for this error:
#0 0x7f7ca923fc2f in ???
#1 0x7f7ca928d02c in ???
#2 0x7f7ca923fb85 in ???
#3 0x7f7ca9229872 in ???
#4 0x7f7ca96b2eca in _ZN9__gnu_cxx27__verbose_terminate_handlerEv
at /tmp/root/spack-stage/spack-stage-gcc-15.2.0-l4zbntofm4hrx2gdenp3ka6ae5wcypni/spack-src/libstdc++-v3/libsupc++/vterminate.cc:95
#5 0x7f7ca96c5ca9 in _ZN10__cxxabiv111__terminateEPFvvE
at /tmp/root/spack-stage/spack-stage-gcc-15.2.0-l4zbntofm4hrx2gdenp3ka6ae5wcypni/spack-src/libstdc++-v3/libsupc++/eh_terminate.cc:48
#6 0x7f7ca96b2a0d in _ZSt9terminatev
at /tmp/root/spack-stage/spack-stage-gcc-15.2.0-l4zbntofm4hrx2gdenp3ka6ae5wcypni/spack-src/libstdc++-v3/libsupc++/eh_terminate.cc:58
#7 0x7f7ca96c5f46 in __cxa_throw
at /tmp/root/spack-stage/spack-stage-gcc-15.2.0-l4zbntofm4hrx2gdenp3ka6ae5wcypni/spack-src/libstdc++-v3/libsupc++/eh_throw.cc:98
#8 0x7f7ca96b72e8 in _ZSt19__throw_ios_failurePKci
at /tmp/root/spack-stage/spack-stage-gcc-15.2.0-l4zbntofm4hrx2gdenp3ka6ae5wcypni/spack-src/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:135
#9 0x7f7ca972d82c in _ZNSt13basic_filebufIcSt11char_traitsIcEE9underflowEv
at /tmp/root/spack-stage/spack-stage-gcc-15.2.0-l4zbntofm4hrx2gdenp3ka6ae5wcypni/spack-src/spack-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:478
#10 0x7f7cb0df25b8 in ???
#11 0x7f7cb0dfcfe4 in ???
#12 0x7f7cb0dff26d in ???
#13 0x7f7cb0d236c2 in ???
#14 0x7f7cb0d247fc in ???
#15 0x7f7cb0d24c9d in ???
#16 0x7f7cb0e18c92 in ???
#17 0x551cfd in __mod_precice_MOD_initialize_precice
at /scratch/ws/ws1/iagtripa-meridonal_m/CFDReboot/Source/Module_Prec/mod_precice.F90:63
#18 0x46d588 in CFDsolver
at /scratch/ws/ws1/iagtripa-meridonal_m/CFDReboot/Source/Control/main.F90:445
#19 0x46b0ac in main
at /scratch/ws/ws1/iagtripa-meridonal_m/CFDReboot/Source/Control/main.F90:98
prterun noticed that process rank 2 with PID 88949 on node verleihnix exited on
signal 6 (Aborted).
I am attaching the xml file also for your reference.
Please provide me information on the source of this error.
Here, you provide a custom exchange directory.
Rank 0 of the m2n acceptor (SolverOne) will try to write a communication file to the exchange directory in the precice-run/XX/ directory. XX being the first two letters of the file hash.
It looks like something is going wrong here. First step is to remove the precice-run directory, which should solve most weirdness.
What is surprising though is that preCICE doesn’t emit a good error message. Are you sure that preCICE: Setting up primary communication to coupling partner/s is the last line in the log?
@Manish please do not ask the same question in multiple threads. I merged the duplicate thread with my answer into this one.
Repeated offenses will lead to a ban.