open TELEMAC-MASCARET The mathematically superior suite of solvers

Hi all

I thought I should mention a bug that I stumbled across in TELEMAC2D (v6p0, but probably others after a brief look at the code). It arises only for certain meshes, without tracers, and only for finite volume calculations. The finite volume scheme used doesn't seem to be important.

After a little digging, the culprit appears to be the DX and DY arrays used by VOLFIN (and its subroutines). In the call from TELEMAC2D, the double arrays AM2%X%R and AM3%X%R are passed as DX and DY to VOLFIN. Unfortunately, the AM arrays has length NSEG (assuming edge-based storage, the default), whilst the DX arrays are expected to have length 3xNPOIN. For certain meshes, one can find that NSEG < 3xNPOIN (it's usually quite close one way or another), and the result is an out-of-range error.

The fix is quite simple. One can simply declare double precision arrays DX and DY in TELEMAC2D, of size 3xNPOIN, and pass them to VOLFIN in place of AM2%X%R and AM3%X%R.

An elegant, though arcane alternative solution is to use the keyword NUMBER OF TRACERS = n, where n>1. This happens to expand the AM... arrays to a size large enough to avoid the out-of-range error.

I hope you find this useful. Apologies if it has already been brought up/fixed!

Happy new year,
Chris

Hello Chris,

Very good remark (and exactly the kind of thing we expect from open source!). We looked at this problem with Riadh Ata and decided to put matrices BM1 and BM2 instead of AM2 and AM3. As they are not symmetric it doubles the available memory size, which gives about 6*NPOIN instead of about 3*NPOIN. That should do it. Actually we do not like to declare local arrays such as DX(3*NPOIN) because it is a hidden dynamic allocation.

With best wishes for 2011,

Jean-Michel Hervouet

Bonjour Jean-Michel,

I agree that changing to BM1/BM2 should fix the problem. Indeed, my suggestion to include tracers makes the matrices AM2 and AM3 asymmetric and expands their size of the relevant arrays to 6*NPOIN. However, it still results in confusing code, as all of the comments regarding BM1, BM2 (and AM2,AM3) refer to tracers. Using the off-diagonal parts of these matrices for a completely different purpose in the finite volume calculation is perhaps a little naughty.

I also agree that the locally-defined DX and DY arrays aren't the best solution, merely one that involved minimal change to the code.

Surely the ideal solution is to define the DX and DY arrays 'globally' via declarations_telemac2d, allocate memory to them in point_telemac2d, and pass them to VOLFIN in the same way.

Anyway, I'm glad that this has been useful.

Best wishes,
Chris

Hello Chris,

Yes you are right, a careful study of all memory allocation in case of finite volumes and creating specific arrays would certainly allow a large reduction of memory.

Regards,

JMH