Problem that src file found but not used

[ZHUOJUN]

Hello,

lately I am facing a problem concerned with user define functions in the src folder, which is more like a "found" but not "used" issue.
I have done so tests on my virtual machine of ubuntu 18.04 with some modified "source codes", and Code Caturne version is 7.0 alpha which I downloaded a while ago from Github. At that time, I directly change some alogrithms or added my models in files that provided by the /src/rayt. And then, I put them into a case's src folder, it works well as I imagined.
But things are different while I installed Code Saturne on a HPC. For stability, I chose version 6.0.7. Already knew that some functions' decleration may be different, I decided to do a simple test by setting isothermal condition for cells and wall, and constant absorption coefficient. Forthermore, my modification is like

Code: Select all

void
cs_rad_transfer_solve(int               bc_type[],
                      const cs_real_t   dt[],
                      cs_real_t         cp2fol,
                      const cs_real_t   cp2ch[],
                      const int         ichcor[])
{
  printf("Hello World\n");
  ......
}

in the file cs_rad_transfer_solve.c file with nothing else. I clicked the compile test in the GUI, and it successfully found my udf with some warnings. But when the case began to run, it seemed that the solver did not use my functions (no printf in the panel) but the pre-compiled ones. Worse, things did not change when I tried the version from Github.

Hence, I indeed need your kind help. My setup are attached below.

Thank you

[Yvan Fournier]

Hello,

On an HPC system, the output of "print" will probably appear in the job output file, not in the "listing" or in the terminal. Did you check there ?

Otherwise, use "bft_printf" to get the message in the run_solver.log file. And if in doubt, you can always use more extreme measures, such as calling "exit" or "cs_exit".

Also, in any case, when you are modifying non-user-defined files in code_saturne (especially .h files), it is safer to modify them in the standard source tree and reinstall the code rather than do everything in a case's SRC file.

Best regards,

Yvan

[ZHUOJUN]

Hello,

Instead of using "printf", this time I changed it to a "fprintf", to output something into a document file, and it didn't work neither. For verification, I removed solve.c but put a cs_user_rad_transfer_absorption.c, which had a same name funcion in it, into SRC folder, then I changed the option from constant to user define in the GUI. This should have made sense, because the below codes from cs_rad_transfer_slove(),

Code: Select all

......
Line: 1240
if (rt_params->imoadf == 0 && rt_params->imfsck == 0) {
	cs_user_rad_transfer_absorption(bc_type, dt, ckg);
	if (cs_glob_rad_transfer_params->type == CS_RAD_TRANSFER_P1)
		cs_rad_transfer_absorption_check_p1(ckg);
    }
......

Sadly, it failed too, with error information of k = -1e+12 which means assignment codes in my UDF did not work.

Thus, it made me wonder that if there were something concerned with faulty configuration(s) or environment that may cause this problem. My proccess of installation did not show any errors or faults, it hence was quite mysterious for me.

Do you have any idea about this problem?

Have a good day

[Yvan Fournier]

Hello,

We have seen this sort of problem in versions available through Ubuntu packages, but only once (unconfirmed) in another type of install.

Could you post also the content of the "run_solver" file present during computation in the execution directory ? One issue I have encountered once led to the code being compiled but "run_solver" calling the default installed version.

Also, could you apply the same tests to files/functions which are called in all cases, independent of the physicla model, such as cs_user_parameters.c ?

Best regards,

Yvan

[ZHUOJUN]

Hello,

The "run_solver" was found in several result folders. While I am not sure the path is execution directory or not, the content presents:

Code: Select all

#!/bin/bash

# Export paths here if necessary or recommended.
export LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu":$LD_LIBRARY_PATH

export OMP_NUM_THREADS=1

cd /home/zhuojun/case1/RESU/preprocessor17

# Run solver.
./cs_solver $@
export CS_RET=$?

exit $CS_RET

Furthermore, I removed my udf for specific physical model, but replaced it by a cs_user_parameters.c, with the core code like

Code: Select all

void
cs_user_model(void)
{
	FILE* fp = NULL;
	fp = fopen("/home/zhuojun/SRC_check.txt", "w+");
	fprintf(fp, "Hello World\n");
	fclose(fp);
}

It did not work, neither. But a difference occurred that for a parameters.c, there was no run_solver in result folder this time.

Sincerely

[Yvan Fournier]

Hello,

The "run_solver" file is deleted at the end of the calculation when the computation finishes correctly, unless you specify run stages to as to avoid the final copy/clean stage. So it is not surprising if you do not have it in some cases.

In any case, it contained "./cs_solver" in the case you posted, so this is the compiled file including your changes, so the problem is not due to the script.

Could you provide more info in your build (config.log, compiler versions, environment modules, ...) and the cluster you run this on ?

Also, do you have any other error appearing in run_solver.log, or in the batch output file ?

A last-resort option might be to build the code using the "--disable-shared" configure option (though this might still not be enough by itself, and need to be combined with another option).

Best regards,

Yvan

[ZHUOJUN]

Hello,

Thanks for your patience. I attached my config.log below. Moreover, the GCC version is 9.3.0, and the Python is 3.8. The HPC info may be described in the performance.log, which tells

System: Linux 5.8.0-53-generic (Ubuntu 20.04.2 LTS)
Machine: hpc-X11DAi-N
Processor: model name : Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
Memory: 385609 MB
Directory: /home/zhuojun/case1/RESU/preprocessor17
OpenMP threads: 1
Processors/node: 80
I/O read method: standard input and output, serial access
I/O write method: standard input and output, serial access

To be clear, the HPC has two chips of CPU, both are 6148.

As far as I see, there is no other errors, or in other words, if I remove my udf and run a simple case, it appears to perform well with original functions.

Latest, I changed the option in the install_saturne.py about shared libraries, from "self.shared = True" to be "self.shared = False" as your Instruction, and it works! I personally suppose that it should have the same meaning of a configure option, and since I will need to use HDF5 and MED, etc, I still go along the path of ./install_saturne.py, not the configure and make which may have a very long suffix.

As the problem seems to be fixed, I am wondering that will this operation lead any hidden danger in the future, and in the long run of using Code Saturne.

Yours respectfully,

Zhuojun

[Yvan Fournier]

Hello,

Thanks for the info.

I assume the issue is due to some configuration option of the compiler on Ubuntu, but do not have info on which option should do this.

The #pragma weak logic we use should add more robustness, but it seems it is not enough here. If you are interested, I can try to generate a small proxy test application to reproduce this on a simple/fast case (as I have never been able to reproduce this on one of our own machines, except by using a "prepackaged" code_saturne build on Ubuntu).

Best regards,

Yvan

PS. Just to make sure, I assume you only have the version of code_saturne you installed, an no "Ubuntu code_saturne package on that machine.

[ZHUOJUN]

Hello,

I am glad to help with the test as long as it won't take you much time, and I am quite sure that I have not installed any "Ubuntu version" packages on the device.

Please inform me more details.

Yours respectfully,

Zhuojun