Welcome, Guest
Username: Password: Remember me

TOPIC: External coupling waves-currents and sediment transport

External coupling waves-currents and sediment transport 1 year 6 months ago #42617

  • Htun Pyae Sone
  • Htun Pyae Sone's Avatar
  • OFFLINE
  • Junior Boarder
  • Posts: 38
  • Thank you received: 2
Dear all,

I am testing to online couple T2D and GAIA while taking the wave results as input. I have read the post #28466 and aware that I should always online couple 3 modules. However, I would like to test the possibility of taking wave results as input for some use cases. Therefore, I am following the section 5.1.8 from the Gaia user_manual and I have some questions regarding this.
  1. The PROSOU.F reads only at one record. Therefore, I adapted it to read at every time step. I would like to know if my adaptation is correct. Please kindly find the file in attachment.
  2. Second, NAMES OF CLANDESTINE VARIABLES is not working for me. I gave all the variables 32 character (name+units). Should I adapt the code in PROSOU.F as well? Currently, I cannot find in which routine it is passing to GAIA.
  3. My final question (my workaround for second question) is it recommended to read the data from T2DBI1 using USER_FORCING_GAIA like in CONDIM_SISYPHE.F?

Thank you very much in advance.

File Attachment:

File Name: user_prosou.f
File Size: 30 KB
The administrator has disabled public write access.

External coupling waves-currents and sediment transport 1 year 5 months ago #42650

  • pham
  • pham's Avatar
  • OFFLINE
  • Administrator
  • Posts: 1559
  • Thank you received: 602
Hello,

I am not a specialist of dealing with waves file or GAIA, but here are some personnal answers (which may be commented by other users maybe).

Your modified PROSOU subroutine seems to do the job, but:
- you have to check it with a test case,
- I am not sure this implementation is optimal as you will have interpolation with twice the call of FIND_VARIABLE subroutine every time step. Maybe you can only do the job once between two records in the wave file?

When you write "NAMES OF CLANDESTINE VARIABLES is not working for me", it would be interesting to see what you have exactly done (steering files, Fortran files at least, release you have used) and to know what is inside your input files, e.g. by copying the log of the command run_telfile.py scan name_of_wave_file.
It seems that GAIA reads the wave file in the GAIA_INIT subroutine if you provide a WAVE FILE in the GAIA steering file and wave information is read at final time step of this WAVE FILE.

If you look at the GAIA example called sandpit-t2d, you can see that the WAVE FILE is defined as input in the TELEMAC-2D and the GAIA steering files.

As soon as you try to modify the standard subroutine, you can do whatever you want.

Hope this helps,

Chi-Tuan
The administrator has disabled public write access.
The following user(s) said Thank You: Htun Pyae Sone

External coupling waves-currents and sediment transport 1 year 5 months ago #42652

  • Htun Pyae Sone
  • Htun Pyae Sone's Avatar
  • OFFLINE
  • Junior Boarder
  • Posts: 38
  • Thank you received: 2
Hello Chi-Tuan,
Thank you very much for your reply.
1. I have checked the PROSOU subroutine with a small test case in both sequential and parallel mode. So far, it is working as intended. I tried to print out the value from one node and compare with the input data. If I use the "GLOBAL_TO_LOCAL_POINT" and read from the partial log file, it is the same as the input value. This is the output from sequential mode:

fig01.png



This is the output from parallel mode read from the partial log file:

fig02.png


From my understanding, it is working. Since it is a small test case, I do not notice much changes in simulation time. I will try to interpolate as you suggested.

2. I tried to use "NAMES OF CLANDESTINE VARIABLES" with the littoral case in the version v8p4r0. I attached all the files that are modified. Here is the information about the input wave file:


fig03.png


The error is :
"MISSING WAVE DATA
WAVE HEIGHT HM0
PEAK PERIOD TPR5
MEAN DIRECTION"

3. Sorry that I did not make myself clear in the previous post. I have looked at the sandpit-t2d example. I also want to read the wave parameter for GAIA at every time step. If "NAMES OF CLANDESTINE VARIABLES" works, I do not need to read the wave parameter from GAIA separately using "WAVE FILE". Is my understanding correct?

In SISYPHE, the CONDIM_SISYPHE is called every time step and I can modify the "USER_CONDIM_SISYPHE" and read it. In GAIA, "USER_FORCING_GAIA" is called without any variables. If I modify the "USER_FORCING_GAIA" subroutine to read from "WAVE FILE", I also have to modify both "GAIA_INIT.F" and "GAIA_PREPARE_STEP.F" where it is called. Is that right?

Thank you very much for your time and help.

Best regards,
Htun

File Attachment:

File Name: t2d_littoral.cas
File Size: 3 KB


File Attachment:

File Name: gai_littoral.cas
File Size: 1 KB
The administrator has disabled public write access.

External coupling waves-currents and sediment transport 1 year 5 months ago #42669

  • pavans
  • pavans's Avatar
  • OFFLINE
  • Moderator
  • Posts: 46
  • Thank you received: 17
Dear Htun,

First of all, thanks for signaling the problem with CLANDESTINE VARIABLES. Your error comes from GAIA which doesn't recognize wave variables coming from the binary file read in TELEMAC-2D. It seems that the procedure given in section 5.1.8 of GAIA's user manual needs to be updated. I try to find a solution and update it in the next days.

When using WAVE FILE in GAIA, GAIA will read wave data at the last record in the wave file (and you don't need to use CLANDESTINE VARIABLES in TELEMAC-2D).
In your case, for unsteady flow simulation, it is suggested to modify the user_forcing_gaia subroutine which is called at every time step.
Even if the subroutine is called without any arguments is not a problem since you have the USE DECLARATIONS_GAIA statement. You don't have to modify the subroutines GAIA_INIT and GAIA_PREPARE_STEP.

I'm sorry but we do not have a built-in example where user_forcing_gaia is used. We are interested in your feedback.

Hope it helps,
Sara
The administrator has disabled public write access.
The following user(s) said Thank You: Htun Pyae Sone

External coupling waves-currents and sediment transport 1 year 5 months ago #42679

  • Htun Pyae Sone
  • Htun Pyae Sone's Avatar
  • OFFLINE
  • Junior Boarder
  • Posts: 38
  • Thank you received: 2
Hello Sara,

Thank you very much for your reply. I will keep updated here and will ask if there is any doubt.

Best regards,
Htun
The administrator has disabled public write access.

External coupling waves-currents and sediment transport 1 year 4 months ago #42857

  • Htun Pyae Sone
  • Htun Pyae Sone's Avatar
  • OFFLINE
  • Junior Boarder
  • Posts: 38
  • Thank you received: 2
Hello Chi-Tuan,
Regarding your comment "I am not sure this implementation is optimal as you will have interpolation with twice the call of FIND_VARIABLE subroutine every time step. Maybe you can only do the job once between two records in the wave file?"
Do you mean I should did the interpolation before hand and read the file? Or is there any better way to do so? Or an example routine?
Thank you very much in advance.

Best regards,
Htun
The administrator has disabled public write access.

External coupling waves-currents and sediment transport 1 year 3 months ago #42998

  • pham
  • pham's Avatar
  • OFFLINE
  • Administrator
  • Posts: 1559
  • Thank you received: 602
Hello Htun,

If you read $HOMETEL/sources/utils/bief/find_variable.f subroutine, you can see that if you give TIME rather than RECORD e.g., there is a search for records between which TIME is, then an interpolation of values for this specific time.

As you call it every time step, the procedure is done from scratch at every time step (whereas perhaps the values have not changed a lot).

The question is, do you need to have interpolated values at every time step or a value computed at the previous record is OK or a few time step before? That may save time for the interpolation step inside FIND_VARIABLE.

Maybe you can decide a period of time during which the values are kept constant and adjust the call to FIND_VARIABLE from time to time (similar to th goal of the keyword COUPLING PERIOD FOR TOMAWAC).

If it sounds OK for you, a simple approximation is to keep the values from TIME when RECORD is changed until RECORD+1.

But the choice is from you with a balance between accuracy you search and CPU time. If you do not see any time loss, you can continue with this implementation but I prefer to warn you for potential optimisation.

Hope this helps,

Chi-Tuan
The administrator has disabled public write access.
The following user(s) said Thank You: Htun Pyae Sone

External coupling waves-currents and sediment transport 1 year 3 months ago #43000

  • Htun Pyae Sone
  • Htun Pyae Sone's Avatar
  • OFFLINE
  • Junior Boarder
  • Posts: 38
  • Thank you received: 2
Hallo Chi-Tuan,

Thank you so much for your help and explanation. Sorry that I forget to update this thread.
I have experienced at hand the bottleneck of IO especially on the cluster with InfiniBand. The previous implementation works well if I run on a local storage. I search and mimic other people's approach to taking the meteorological data.
I used find_variable.f to read at the input TIME and TIME+1 and stored them in new variable(saved). After that, I interpolate from those and update them at particular period (similar to COUPLING PERIOD) as you mentioned. Now it is working well. :)
I should have followed your advice and test it earlier. Thank you very much.
P.S. The doxygen documentation is very helpful.

Best regards,
Htun
The administrator has disabled public write access.

External coupling waves-currents and sediment transport 1 year 3 months ago #43001

  • pham
  • pham's Avatar
  • OFFLINE
  • Administrator
  • Posts: 1559
  • Thank you received: 602
Good news if it is working well for you
The administrator has disabled public write access.
The following user(s) said Thank You: Htun Pyae Sone
Moderators: Pablo, pavans

The open TELEMAC-MASCARET template for Joomla!2.5, the HTML 4 version.