open TELEMAC-MASCARET The mathematically superior suite of solvers

Many thanks Chi-Tuan, am now back off leave. I think I've still got the set up to be able to test this. I will endeavour to get you a response before your deadline.

Cheers

David

Hi Chi-Tuan,

Thanks very much for the effort - this will make a substantial impact to the simulation times.

I have tested this on a model recently and can confirm it works. The only issue is that if the binary atmospheric file ends on the last simulation timestep it crashes as its looking for the next record for interpolation. I don't recall this previously happening. Perhaps there needs to be an if condition to check if the we're on the last record to avoid this?

I'm aware that the binary files are possible inputs for various other modules, for instance in WAQTEL etc. Would these fixes improve read speeds on any binary inputs or only those specifically for meteorological inputs? In saying that I haven't tested for this issue for other inputs apart from meteorological.

I've also used the variable names you mentioned in your previous post as per the WAQTEL definitions. I assume that the other long variable names such as 'WIND VELOCITY U', 'SURFACE PRESSURE' etc. will not work with these modifications? Perhaps we should modify the manual to only suggest the abbreviated variable names across all the modules in that case?

Regards,
Toby

Hi Chi-Tuan

To give a quick update, have done some initial testing. The code worked for me without any errors (using v8p4r0). The code ran in 2D and 3D and coupled to WAQTEL with multiple tracers, both active and passive. Have only run on short runs at the moment so the speed up over a 48 hour simulation was marginal, but have got a couple month long simulations running at the moment so can give an update in due course.

Also tested a computation restart and that seems to be running fine without any trouble.

Not got to the end of the atmospheric file in a simulation yet so haven't seen the error Toby got at the end of file error yet but will get there soon.

Cheers

David

Hi Chi-Tuan

Finished some further testing. So saw a speed up of about x2.4 over the month long simulation, so am definitely a fan of the new code!

Regarding what Toby saw with regard to the end of file error, yes I encountered that as well. Obviously a simple way round is to make sure the atmospheric file is longer than you need but that's a bit of a crude and inelegant solution.

In my case, the atmospheric file finished on 23:00 on the last day of the month, so set my simulation to finish then, but when it gets to the last timestep, instead of stopping the interpolation on the last interval, its looking for effectively 00:00 on the next month: RECORD: 768 IS NOT WITHIN [0, 767].

Maybe it needs something like an IF statement somewhere along the lines of
IF (ITIMEB2.EQ.NTIMEB) ITIMEB2 = ITIMEB1

Thoughts?

David

Hello David and Toby,

Thanks a lot for your feedback, very appreciated.

Please find enclosed a modified meteo_telemac module to solve the issue of last time step at final time of the binary atmospheric data file.

Can you please try it and tell me if it is OK for you please? Ideally before Thursday September 14th.
I have tried it both for telemac2d/wind_txy and the example Toby had sent me, it works without differences for the results file.
If you do not have time, just have a quick look at the implementation (only a few lines added in SYNC_FIC_BINARY concerning index NTIMEB) and tell me if it sounds good to you.

Thanks,

Chi-Tuan

Hello Toby,

This modification enables the use of every meteo variable available in the METEO_TELEMAC module, not only limited to wind velocity components, air pressure or air temperature.

For sure, documentation is to be updated.

I think if it is OK, this modification will erase the old method with METEO_FROM_BINARY_FILE in the sources folder but I will let this in the wind_txy binary example as a 2nd method implemented with Fortran files (meteo_from_binary_file, meteo_set_var_names and read_bin_2d) for users who liked old fashion and prefer to keep their old file format, even if slower.

Chi-Tuan

Hi Chi-Tuan

Can confirm the new modifications fixed the end of file error.

Looking forward to this becoming part of the trunk code!

Many thanks

David

Hi Chi-Tuan,

Confirmed working from my side as well. Thanks again.

Regards,

Thank you very much for your feedbacks David and Toby.

Modifications were merged with the main last week. You can also have them in branch v8p5 which is available and will be the basis of future tag v8p5r0.

Any feedback of using branch v8p5 or main is welcome for new features or enhancements.

Chi-Tuan