open TELEMAC-MASCARET The mathematically superior suite of solvers

Hello,

With V6P3, I often used MESH%KNOGL%I to apply something to a point which I knew it global number.
I am trying to do the same with V7P0. I am using the function GLOBAL_TO_LOCAL_POINT because MESH%KNOGL%I was deleted but the computation time is so much longer.
I have tested in corfon and strche to implement bathymetry and Strickler in an empty grid (1 million nodes). The computation times are very different :
- V3P3, 131s
- V7P0, 1363s
This test was for corfon and strche only called one time so it could be acceptable but if I want to check something at every time step it will be a serious issue for computation time...

Why MESH%KNOGL%I was deleted?
Can we expect an optimization of GLOBAL_TO_LOCAL_POINT?
Or is there an easy way to implement an equivalent to MESH%KNOGL%I?

Regards.

Hello Nicolas

This is normal to have such differences in CPU time but this is the price to pay to the policy we have chosen.
Actually, KNOGL has been removed because for HPC cases with a very big number of processors, this array is very expensive since it have the dimension of the global mesh and it has to be managed by all processors. One tentative solution was the use of this subroutine. However, as it is clearly noted in its header, the programming is qualified by "naive" and needs, for sure to be optimized.
The cost is mainly due to the loop over all the NPOIN. Nevertheless, the statistcs are interesting while this will motivate us to proceed to the optimization.

with my best regards.
Riadh Ata

Hello Riadh,

I understand why KNOGL was removed, you need to make a choice and it is this one ok.
I have already read the GLOBAL_TO_LOCAL_POINT function, it optimization was clear of course because of the loop on NPOIN.

What do you advise for working on a point when you know the global number and without GLOBAL_TO_LOCAL_POINT?
In my case and for CPU time, maybe the better way is to write an homemade KNOGL?

Regards

Hello Nicolas

I believe that for a number of processors and a mesh fairly not very big, the solution based on KNOGL is much more advantageous. Maybe we can keep both solutions and give users the choice.
For your case, you can start by build your own KNOGL. waiting for a better solution, hopefully.

with my best regards.

Riadh

Ok, thank you for the advise.
Can you tell me in which subroutine KNOGL was built before V7P0?

Regards

I'm not in my office but I think that there is a subroutine called paragl.f in bief library.

my best regards
Riadh

I have implemented the homemade version, the CPU time is really good in V7P0 : 22s with the same configuration than previously.

Another question, is there a variable in Telemac with the number of points in all the mesh (equivalent of NPOIN in scalar)?

Regards

Hello,

We would be keen to have a better implementation of function GLOBAL_TO_LOCAL_POINT, probably a dichotomy would be much faster, the only requirements is that we must not use an array of the size of the original mesh.

The original number of points is the maximum value of array KNOLG over all the processors, but we did not create a function for doing that.

The real questions are why do you need a loop on all points with the function GLOBAL_TO_LOCAL_POINT and why do you need to have the original number of points, because we suppressed KNOGL after realising that there was not a single algorithm in the whole system that really requested it. You probably need it for some data that could perhaps be in a selafin file that could be partitioned, this is what we did for the FRICTION DATA FILE for example.

With best regards,

Jean-Michel Hervouet

Hello Jean-Michel,

Ok for the function GLOBAL_TO_LOCAL_POINT.

Ok for KNOLG.

I use global numbers to have some data on points as you think. It is certainly not the best optimization, but I use to add some ascii files with this data. I will have a look to FRICTION DATA FILE to find a better way.

Regards.