open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi,

I am having some difficulties to run TELEMAC-3D on the world oceans.
I have a working version for TELEMAC2D for all kinds of resolutions.

here is a google drive folder where anyone can download, edit and try it: drive.google.com/drive/folders/18nHcPTj4...CwDdk6h_?usp=sharing

The reference CAS file for this problem is(noTF for no tidal flats)

The problem I have for T3D is the following:
- I made sure all the triangles respect the CFL condition (<1). I had to clip depths accordingly.
- I used all distributives schemes for advection (3,4,5) and the error is always the same
- the error is more obvious with Scheme 5 (MURD+PSI), like shown on the image below:



I can't isolate from where the error is coming from.
I have put inbief in the user_fortran3D as I'm 99% sure it comes from there.


in INBIEF routine, the correction for triangles crossing is done once for MESH2D in the LONGITU routine. So the relative mesh coordinates (XEL & YEL) are corrected once and for all for triangles accross the IDL (+/-180 meridian).

Maybe there is another value that needs correcting and that did not draw my attention?

Hi,

I'm going to download some of your slf files and load them into Blue Kenue 3.12.22 - beta to see if I notice anything odd that Blue Kenue might be doing to your data; I'm assuming that you're using BK...

I'll let you know (hopefully today) if I notice anything obvious from the BK side...

Kindly... Alan

My first observation is that the 2D mesh is odd...

Loading the 20km/era5_202307 file gives the following 2D mesh (once zoomed in) containing a large number of horizontal lines:



Is that really what you want?

Kindly... Alan

Loading 20km/era5_202307.slf seems to be displaying quite nicely in a Spherical View... so, no obvious issues from what I can see in Blue Kenue



Sorry I can't help more! Hopefully someone else can...

Kindly... Alan

Alan: It's a contiguous global mesh, hence the connecting element edges across the -180 to +180 boundary. Only properly viewed in a Spherical view.

Tom: I'm curious what tools you used to generate this mesh.
It looks great!
Sorry I can't comment on your problem

Martin

thanks both for your replies already.

I used pyposeidon which is a framework that englobes:
- meshing (via GMSH/JIGSAW/oceanmesh)
- modeling (SCHISM/TELEMAC)
- and post-processing (matplotlib/mayavi/holoviews)
I presented it at the last SciCo.

I am working actively on a repo that enables people to reproduce the same mesh.

I'd still have to add the scripts and the folders for the meshes I added on the drive, but in theory you should be able to mesh the versions that are already there (50, 30, 6 and 3km).

For more context, we try with my team to compare results in order to tackle the infinite number of problematics when you go global:
- compare our results on TELEMAC and SCHISM (in 2D and soon I hope in 3D) with NOAA's STOFS2D results
- compare wind sources (ECMWF vs GFS)
- more in-situ data sources (we use searvey which combines IOC / COOPS / USGS, soon wave buoy data from NDBC too)

I found the fix.

After doing a research for MESH2D%X in the source code, I found where the problem was coming from.

The problem was in the FLUPRI (flux calculation) routine. The relative distances are calculated in MERCATOR.

A correction for the polar distortion (like done in LATITU routine) and the triangles crossing the +/-180 fixed everything. (I updated the user_fortran3D accordingly)

I also had to shut down the calculation of MESH%SURDET in INBIEF

Well done! I'm sure everyone appreciates your effort!

Kindly... Alan