open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi,

I often need to use a nested grid approach whereby depth-averaged velocities water levels are taken from a larger grid.

I have some custom source code modifications that read in these values for each boundary node and interpolate in time from a text file. BORD3D is then modified to manually change the imposed FS and UV boundary conditions on each boundary node. This works well in T2D with depth-averaged velocities but in T3D, the only way I can figure out how apply the values is to take the depth-averaged velocitity and apply as constant over all layers which seems to be leading to strange numerical issues.

Ideally, I would like to only impose the values as a depth-averaged velocity and let the model determine a logarithmic profile. Reading the manual, it appears that one can impose U and V velocity components from the liquid boundary file (although constant for a given boundary segment). It is also stated that 'when processing a prescribed flow rate or prescribed velocity boundary a VERTICAL VELOCITY PROFILE can be specified. A logarithmic velocity profile is exactly what I'm looking for but looking at the source code I can't seem to see how this is implemented.

As far as I can see, the logarithmic profile is only considered in BORD3D when imposing discharge boundary conditions at around Line 374 through the call to VEL_PROF_Z. I cannot see any such call when imposing velocities on the subsequent lines

Does anybody know if it may be possible to prescribe only depth-averaged U and V components and let the model determine the logarithmic profile?

Thanks

Hello Toby again,

You are right, in standard TELEMAC-3D, VELOCITY VERTICAL PROFILES can only be used with prescribed discharge. If you want to use this feature for prescribed velocities, you have to implement it in USER_BORD3D or BORD3D subroutines.
USER_BORD3D is called at the end of BORD3D and it will overload standard treatments. Depth-averaged U and V components are stored in UBOR2D arrays (you can see an example of how to use them in BORD3D) and then you have to multiply terms by VEL_PROF_Z with the correct indices (you can also have a look in BORD3D).

Hope this helps,

Chi-Tuan

Thanks again for your helpful feedback.

I actually made the exact modifications you mentioned while I was playing around with this last week. I multiplied the depth-averaged velocities by the terms from VEL_PROF_Z but didn't continue with the exercise.

One thing that was worrying me a bit is that there seems to be some kind of correction on the velocities later in BORD_3D when applying discharge boundary conditions so I was unsure whether something similar needed to be implemented with this modification. I didn't get to the point of checking whether the loagirthmic profile that was produced gave exactly the same depth-averaged velocity that was originally specified.

Hello Toby,

You can find enclosed what could be implemented (in USER_BORD3D or directly in BORD3D, that could be added in next release if you also confirm it works for you). It seems to work for a simple channel (modified TELEMAC-3D example canal).

When prescribing discharge contrary to velocities, there are 2 steps: the 1st one is to prescribe the velocity profile, the 2nd one is to adjust the velocity (but not the velocity profile) to respect the discharge to impose through the liquid boundary. This is not needed when directly prescribing velocities at the liquid boundary.

Hope this helps (or other users),

Chi-Tuan

Hello Toby,

Do you (or other users) have any feedback for my proposal? If it is OK, I can merge with the main.

Chi-Tuan

Hi Chi-Tuan,

Sorry for a long delay in getting back to you. Haven't had a chance to focus a lot of attention on the forums.

I haven't had a chance to test the proposed change but I don't see why it would be a bad option to include.

Personally I feel that the user documentation has become quite confusing with new features not discussed and/or the wrong information mentioned. For instance the T3D user manual at present reads:

"When processing a prescribed flow rate or prescribed velocity boundary, the user has the keyword VELOCITY VERTICAL PROFILES to specify which "vertical" velocity profile should
be prescribed by TELEMAC-3D (one value per liquid boundary). The options for that keyword
are"

This sent me around in circles digging through the code because it is only valid when prescribing a flow rate (not a velocity).

A couple of other things that I think would be good to update in future versions:

- The ability to prescribe sediment concentrations to sources when coupling GAIA to T2D - ideally through the sources file so variable concentrations can be considered. There is some custom code modifications floating around which I have used (which works for constant sediment concentrations) but I feel this is a common requirement and is implemented already across most models so would be good to see it included. I also believe its already implemented in T3D.

- A rework and simplification of the model coordinate system inputs. I think the user should only be asked to specify the input grid coordinate system (cartesian, Lat/Long, Mercator, UTM etc.). For Lat/Long and UTM, there should be no requirement for specification of origin points and all other features such as Coriolis, TPXO boundaries etc. should just automatically work. I realise this is a lot of work but I think its very confusing at the moment and would go a long way to improving the overall model capabilities.

- Option for feedback between sources (e.g. for intake/outtake recirculation studies). This can be achieved through custom code modifications but it would be nice to see implemented as something that could be define within the CAS file.

Anyhow these are just a few suggestions off the top of my head. Let me know your thoughts.

Regards,
Toby

Oh one other thing...

I think it would be nice if the user could select the constituents they want to use from the provided tidal database and also apply adjustments to the phase and amplitudes of each for calibration purposes.

Hello Toby,

No problem for the delay. What is interesting for me is to get answers to questions.

Some answers from me to what you have written:

"I don't see why it would be a bad option to include". I agree this option is missing but my question was to be sure the implementation is good. I could have tested it for a simple test case but if it were also confirmed for another example, trust would be higher. Better to do it before pushing on the main than after.

"Personally I feel that the user documentation has become quite confusing with new features not discussed and/or the wrong information mentioned."
I agree that everything is not perfect in the TELEMAC system. Sometimes, new features or fixes are committed without updating documentation, we try to do our best.
For wrong information, every time we are aware, we try to update. But sometimes, the wrong information has been existing since a long time and nobody noticed it (in the case of prescribed velocity boundary and VELOCITY VERTICAL PROFILES, the mistake seems to be here for at least 10 years! Sorry). Wrong information or bugs often occur when the feature is not used or tested, the example database does not test the whole features and options, we are aware.

Any feedbacks, comments, suggestions to improve documentation or sources are welcome and needed, you can ask to have a gitlab account to do so.
The TELEMAC system is open source and benefits from users feedback (ideas, implementation, etc.). Do not forget that the main developers cannot do everything and any help is welcome.

Just a reminder concerning GAIA. The module is quite new compared to TELEMAC-2D or TELEMAC-3D e.g.
Some new features or fixes have been committed quite recently and improvements are still in progress.
It could be surprising that some features may currently work better in 3D than in 2D but the way hydrodynamics was used in SISYPHE and SEDI3D was different and when unifying 2D and 3D for sediment transport into GAIA, changes are needed in 2D. I suggest you to create a gitlab issue to describe what you have noticed and what may be missing to your point of view, add suggested part of source codes etc. I do not think people who develop GAIA read every post in other sections different from GAIA/SISYPHE.

For the model coordinate system input, as already discussed, I agree that it may be confusing for users. The best and quickest things that can be done currently is to well document the issue. It is not straightforward to gather several features and keywords and produce simple code.
To a user point of view, it would be easier for sure, but some options cannot be automatically chosen for the user (or at least well done). As already told in other topics, TELEMAC (2D or 3D) need to compute in projections and if you provide latitude/longitude, the origin points need to be given for the Mercator projection. That is the way this projection is implemented in the TELEMAC system and the trick to convert longitude/latitude and the modified equations for plane projection. The code itself may compute longitude and latitude of origin point depending on the geometry file, but maybe not the most relevant.
For not so large extent, converting longitude/latitude to UTM may be a solution (and in that case, no need for origin points), but it is to be checked that the theory to change the equations are still good. Moreover, I do not know if the projection of a domain covering many UTM zone (e.g. 4-5 or more) do not alter results (it may be the same currently for Mercator projection).
Many things to check for theory, implementation etc. before finding the good and easiest solution, I think.

"- Option for feedback between sources (e.g. for intake/outtake recirculation studies). This can be achieved through custom code modifications but it would be nice to see implemented as something that could be define within the CAS file."
I think a gitlab issue with more description, example is needed to show what already exists and what is missing. Any example of partial (or whole) source code is welcome at this step. I have a few ideas in mind but perhaps not covering everything other users may have.

"I think it would be nice if the user could select the constituents they want to use from the provided tidal database and also apply adjustments to the phase and amplitudes of each for calibration purposes."
Good idea for a new gitlab issues, which may be improved by other users'feedback.

Chi-Tuan

Hi Chi-Tuan,

Appreciate the feedback. Hope my post didn't come across the wrong way. I definitely appreciate the effort that the development team puts into the project and wish I had the programming skills to contribute in a more meaningful way. I do realise that its a massive job and things can slip by etc.

In any case, once I get a chance (hopefully in the next few weeks) I will try to implement your code and get back to you with some feedback.

For the remaining items I've brought up, these are mostly things I've come across working with Telemac quite frequently. I will try to raise them on gitlab (this is new to me, so need to wrap my head around it).

Regarding the UTM projection, I do believe that some accuracy is lost over large domains where the projection starts to fall apart over multiple zones (otherwise multiple zones wouldn't be used in any case). I need to look into it more and perhaps gain some inspiration from other open source projects. I believe HRW developed the global earth model using telemac but not sure what type of coordinate system was used.

Best Regards,
Toby

Already a bit off topic on this thread now but do you think it might be worth trying to implement a spherical coordinate system formulation so that larger domains could be accurately modelled?

I realise this would be a huge amount of work and I’m not exactly sure what would be required but it would be a huge upgrade to the model capabilities