open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi Chi-Tuan,

Thank you very much for this solution. However, when I try this, I have strange run results and I have errors if I try to run the steering file in parallel mode (www.opentelemac.org/index.php/kunena/oth...-boundary-node#43781).
What seems to happen is that the shifted geometry file does not contain an IPOBO value anymore (or at least it can't be read by Blue Kenue). On my non-shifted mesh, this problem did not appear.

Do you know if I can shift my mesh and keeping the IPOBO value ? I attach my mesh and steering file.

Thank you very much,

Coline

Hi Coline,

I don't know why your slf file doesn't contain IPOBO values
but thankfully the fix is very simple.
(well it's not a FIX per se, but rather a workaround)

1. File->New->SELAFIN Object...
2. drag the FOND object onto this new object. (NOT ipobo)
3. File-Save the new SELAFIN object

And you're done.

Hope this helps... Martin

Hi Martin,
Thank you for your answer. Unfortunately, this does not work in my case because saving the new selafin changes position of tightest nodes, this is teh reason why I shifted it in the first place using python with Chi-Tuan solution.

I need a way to shift it but keep the ipobo value readable somehow...

You're probably doing something wrong somewhere in your processing steps...
Martin's solution should work if you well define the origin parameters of your mesh...
Moreover, Using python scripts to shift the mesh shouldn't change ipobo array...
Maybe you should join all your files to allow us to test and see where the problem is...

You're probably doing something wrong somewhere in your processing steps...
Martin's solution should work if you well define the origin parameters of your mesh...
Moreover, Using python scripts to shift the mesh shouldn't change ipobo array...
Maybe you should join all your files to allow us to test and see where the problem is...

Hi Christophe,

You will find attached:
- My mesh generator Mailleur_mer_2.t3m, with submesh maille_terre.t3s and density zones lim_mer_90.i2s, lim_mer_20.i2s, lim_mer_digues.i2s and lim_mer_40.i2s, and the outline limite_modele_etendu.i3s.
- My unshifted mesh (result of run of Mailleur_mer_2), maille_etendue.slf. This one contains the IPOBO variable.
- My shifted mesh using run_telapy : maille_etendue_shifted.slf. This one misses the IPOBO value.

Download link (too many files to put them all here) :
creocean.fromsmash.com/Blue-kenue-files-colinemathias

I did use Blue Kenue 3.4.1 (so did not define origin of my mesh), because the solution to shift data with python would be much easier for me (in my company, everybodey uses version 3.4.1). However, if this still does not work, I will try with the latest version.

Thanks a lot,

Coline

Hi
Will try to find time to look at the files.
One preliminary question: Could you give the exact command used to shift the mesh?
And also a remark: You generate an unshifted mesh saved as an slf file. Doing this, and except if you saved it as a double precision selafin, you necessarily should have a rounding step in the coordinates, then why shifting it after?

Regards

Hi Christophe,

I shifted the mesh with run_telfile.py alter --orig 437682 6922105 maille_etendue.slf maille_etendue_shifted.slf

I shift the mesh because my tidal forcing uses TPXO, and thus I can't run my t2d model in local coordinates only. My guess was that the rounding didn't impact my unshifted mesh because the local coordinates did not have as many digits as Lambert93 coordinates. Shifting it with python does not add an offset to every node but just saves the offset in a "origin" variable (pretty much as when we save with prescribed origin with Blue Kenue alpha version), and TPXO is able to be applied at correct coordinates while everything else happens in local coordinates.

This is what I understood of the process explained in this forum topic, do not hesitate to correct me if I made a mistake.

Thank you very much for your help,

Coline

Hi again Coline,

A quick question if I may...

Why not just use a double precision slf file?
Yes the file gets bigger (which was a serious constraint
in the past) but nowadays disk space is so inexpensive
that I can't see it being a problem.

Cheers... Martin

Hi again Coline,

A quick question if I may...

Why not just use a double precision slf file?
Yes the file gets bigger (which was a serious constraint
in the past) but nowadays disk space is so inexpensive
that I can't see it being a problem.

Cheers... Martin