Hello,
I have several problems when trying to do coupling calculation with Syrthes, thank you in advance for giving me some advice.
- I 'd like to know how can I RESTART a calculation from a former calculation result? I've chosen the "restart" block in GUI of Syrthes and Code_Saturne, but it doesn't work.
- When I start the coupling calculation, it seems to work normaly, no error appears. And in the RESU_COUPLING folder, I get the results of Saturne part, but in the folder of results of Syrthes, there are no results, I didn't get a POST folder there. When I test my case seperately with the two softwares, both can run.
- When I use multiple processors to run my case, it doesn't accept, it always use one single processor for Syrthes and one single for Saturne.
Thanks a lot and have a nice Friday and weekend!
Luyi
Problem concerning about coupling calculation with Syrthes
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Problem concerning about coupling calculation with Syrth
Hello,
Could you post more details, as explained in the forum usage guidelines ?
For the parallel case, at least send us your runcase_coupling file. For Syrthes results, your syrthes .syd file.
Regards,
Yvan
Could you post more details, as explained in the forum usage guidelines ?
For the parallel case, at least send us your runcase_coupling file. For Syrthes results, your syrthes .syd file.
Regards,
Yvan
Re: Problem concerning about coupling calculation with Syrth
Hello Yvan,
Thanks for your reply and sorry that didn't provide enough details.
I put the .xml file for Code_saturne, .syd file for Syrthes and runcase_coupling in the attachement.
I got same additional questions
- Is syrthes version 4.0.1 OK for coupled calculation case, because I saw in another topic, you suggested to use version 3.0
- Actually the last time I post my question the Code_saturne gave the results, now it does only one time step's calculation, it stops without finish the 100 time steps, and still no error document appears. I put the listing in the attachement. And for the informaition, it seems bajsi have posted a similar post, this is the lien http://code-saturne.org/forum/viewtopic.php?f=2&t=1058
- I've entered TempC=0 in GUI of the reference value of initialization, but in the water.xml I got </initialization> <reference value><temperature>1273.15<./temperature>, why there is 1000 K in addition?
- In the .xml and .syd the number of proc is 2, but in the runcase_coupling, I got n_procs_min:1 automatically. So I have got to correct it manually, however it appears the error in terminal which didn't raise problem when n_proc_min was 1, the error is in the attechement in the name of <error in the terminal>.
Too many questions
Thank you for answering
Luyi
Thanks for your reply and sorry that didn't provide enough details.

I put the .xml file for Code_saturne, .syd file for Syrthes and runcase_coupling in the attachement.
I got same additional questions
- Is syrthes version 4.0.1 OK for coupled calculation case, because I saw in another topic, you suggested to use version 3.0
- Actually the last time I post my question the Code_saturne gave the results, now it does only one time step's calculation, it stops without finish the 100 time steps, and still no error document appears. I put the listing in the attachement. And for the informaition, it seems bajsi have posted a similar post, this is the lien http://code-saturne.org/forum/viewtopic.php?f=2&t=1058
- I've entered TempC=0 in GUI of the reference value of initialization, but in the water.xml I got </initialization> <reference value><temperature>1273.15<./temperature>, why there is 1000 K in addition?
- In the .xml and .syd the number of proc is 2, but in the runcase_coupling, I got n_procs_min:1 automatically. So I have got to correct it manually, however it appears the error in terminal which didn't raise problem when n_proc_min was 1, the error is in the attechement in the name of <error in the terminal>.
Too many questions

Thank you for answering

Luyi
- Attachments
-
- syrthes_data.txt
- .syd
- (2.83 KiB) Downloaded 242 times
-
- runcase_coupling.txt
- (5.76 KiB) Downloaded 245 times
-
- water.xml
- (7.52 KiB) Downloaded 229 times
Last edited by luyitang on Mon Mar 25, 2013 8:16 am, edited 1 time in total.
Re: Problem concerning about coupling calculation with Syrth
The additional attachements.
Best regards
Luyi
Best regards
Luyi
- Attachments
-
- listing.txt
- (35.63 KiB) Downloaded 243 times
-
- error in the terminal.txt
- (3.74 KiB) Downloaded 232 times
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Problem concerning about coupling calculation with Syrth
Hello,
Here are some answers, not in order:
Please upgrade to Code_Saturne 3.0 final (released last Friday). Quite a few bugs have been fixed, and your data should still be compatible.
The 1000K addition to temperature should not be there, but might be due to an example. If you reload the case under the GUI, do you see that addition ? If so, and you correct the temperature, does it still appear in the xml file ? If it does, you can edit it by hand, but there may be a bug, so please confirm us what you obtain. I seem to remeber a similar issue some months ago, so it it is a bug, it may have been fixed in 3.0.
For the single time step after restart, remember that you need to increase the number of time steps in Code_Saturne (and I believe SYRTHES) to be larger that the value at restart. If you forget this, you may have one iteration (you would have zero without coupling, but some specific handling of code stopping with coupling can lead you to have one iteration, which looks a lot like what you get here).
Note the first coupled code that stops stops the other, so a good idea is to set a very high number of time steps in one code, and set the required number in the other, to control the coupled case more easily.
Finally, regarding the parallel run, the n_procs_min in the runcase coupling should have priority (I m sure for Code_Saturne, but for SYRTHES, it may be safe to use the same value here and in the syrthes .syd file).
Your error with SYRTHES in parallel looks like a partitioning problem, which may be related to the SYRTHES installation (especially if METIS is built with shared libraries). Do you have any more details in the SYRTHES run directory ?
Regards,
Yvan
Here are some answers, not in order:
Please upgrade to Code_Saturne 3.0 final (released last Friday). Quite a few bugs have been fixed, and your data should still be compatible.
The 1000K addition to temperature should not be there, but might be due to an example. If you reload the case under the GUI, do you see that addition ? If so, and you correct the temperature, does it still appear in the xml file ? If it does, you can edit it by hand, but there may be a bug, so please confirm us what you obtain. I seem to remeber a similar issue some months ago, so it it is a bug, it may have been fixed in 3.0.
For the single time step after restart, remember that you need to increase the number of time steps in Code_Saturne (and I believe SYRTHES) to be larger that the value at restart. If you forget this, you may have one iteration (you would have zero without coupling, but some specific handling of code stopping with coupling can lead you to have one iteration, which looks a lot like what you get here).
Note the first coupled code that stops stops the other, so a good idea is to set a very high number of time steps in one code, and set the required number in the other, to control the coupled case more easily.
Finally, regarding the parallel run, the n_procs_min in the runcase coupling should have priority (I m sure for Code_Saturne, but for SYRTHES, it may be safe to use the same value here and in the syrthes .syd file).
Your error with SYRTHES in parallel looks like a partitioning problem, which may be related to the SYRTHES installation (especially if METIS is built with shared libraries). Do you have any more details in the SYRTHES run directory ?
Regards,
Yvan
Re: Problem concerning about coupling calculation with Syrth
Hello Yvan,
Really thanks a lot for replying so quickly.
Concerning about the 1000K, I tested by reloading the xml file with the right temperature to GUI, in GUI there is no problem, it affiche TempC=0 as usual, and when I save the GUI, the xml file add the 1000K automatically and gives 1270K. So I can be a bug there, I think.
With the help of my colleague, I correct my runcase_coupling, by add "-v ens" for "opt", I get the programme run correctly for the moment.
Thanks so much!
Best regards
Luyi
Really thanks a lot for replying so quickly.
Concerning about the 1000K, I tested by reloading the xml file with the right temperature to GUI, in GUI there is no problem, it affiche TempC=0 as usual, and when I save the GUI, the xml file add the 1000K automatically and gives 1270K. So I can be a bug there, I think.
With the help of my colleague, I correct my runcase_coupling, by add "-v ens" for "opt", I get the programme run correctly for the moment.
Thanks so much!
Best regards
Luyi
Yvan Fournier wrote:Hello,
Here are some answers, not in order:
Please upgrade to Code_Saturne 3.0 final (released last Friday). Quite a few bugs have been fixed, and your data should still be compatible.
The 1000K addition to temperature should not be there, but might be due to an example. If you reload the case under the GUI, do you see that addition ? If so, and you correct the temperature, does it still appear in the xml file ? If it does, you can edit it by hand, but there may be a bug, so please confirm us what you obtain. I seem to remeber a similar issue some months ago, so it it is a bug, it may have been fixed in 3.0.
For the single time step after restart, remember that you need to increase the number of time steps in Code_Saturne (and I believe SYRTHES) to be larger that the value at restart. If you forget this, you may have one iteration (you would have zero without coupling, but some specific handling of code stopping with coupling can lead you to have one iteration, which looks a lot like what you get here).
Note the first coupled code that stops stops the other, so a good idea is to set a very high number of time steps in one code, and set the required number in the other, to control the coupled case more easily.
Finally, regarding the parallel run, the n_procs_min in the runcase coupling should have priority (I m sure for Code_Saturne, but for SYRTHES, it may be safe to use the same value here and in the syrthes .syd file).
Your error with SYRTHES in parallel looks like a partitioning problem, which may be related to the SYRTHES installation (especially if METIS is built with shared libraries). Do you have any more details in the SYRTHES run directory ?
Regards,
Yvan
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Problem concerning about coupling calculation with Syrth
Hello,
I checked the code, and the reference temperature seems to be set correctly only when using a gas combustion or atmospheric model, but it seems it is used in an automatic manner only in those cases.
Still, it would seem more logical for it to be at a more reasonable value in other cases, , and a strange value in the "listing" is not reassuring, even if not used.
When not using an xml file, it is set to 293.15, so that should be the default.
I'll check with colleagues working on physical models and on the GUI if it is OK to change this in 3.0.1 (as data setups must remain compatible in all 3.0.x series), and we will definitely change it in 3.1.
Regards,
Yvan
I checked the code, and the reference temperature seems to be set correctly only when using a gas combustion or atmospheric model, but it seems it is used in an automatic manner only in those cases.
Still, it would seem more logical for it to be at a more reasonable value in other cases, , and a strange value in the "listing" is not reassuring, even if not used.
When not using an xml file, it is set to 293.15, so that should be the default.
I'll check with colleagues working on physical models and on the GUI if it is OK to change this in 3.0.1 (as data setups must remain compatible in all 3.0.x series), and we will definitely change it in 3.1.
Regards,
Yvan