open TELEMAC-MASCARET The mathematically superior suite of solvers

While running a 3D KEP turbulence model with wind and rain, I was regularly getting non-convergence in the KEP part using the default solver and preconditioner. I looked at other solvers, and finally used CG combined with preconditioner #34. This seems similar to the solution approach Casuli where the where preprocessing in the vertical simplifies the overall matrix. My problem is an estuary lake with catchment flows

For most runs this works very well with the KEP solution requiring very low number of iterations for convergence. However occasionally (and what appears quite randomly) this method crashes due to System Ill Defined errors. Sometimes this is brought on by minor changes to calibration parameters and lead up results suggest that velocites and water levels etc are well behaved. It only occurs in the KEP diffusion step.

Is this a normally expected behaviour, I would expect the vertical structure should be well behaved under all conditions for a direct solver in the situation I am working with.

Is there any advice for the 'best' or most robust solvers to use?

Cheers
John

I can add that I am using one horizontal plane in the vertical grid, due to stratification features (total of 10 planes). So I do have crushed planes.

Part of the problem chasing this type of is the lack of info in the error messages. In this case just a very brief description that a bad condition has been seen is notified.

A previous post of mine elsewhere highlighted the advantage of better error messages, giving the 2d location/node id (and plane if appropriate) and what routine called this routine (effectively a type of callback). The latter is because at solver level many different hydraulic processes can call the same solvers and currently there is not ways to easily advise what process tree is being used.

The 2d location/nodeid helps because even in the 3d processes a main input parameter is the local bed levels (plus other spatially defined parameters). The location information allows inspection of the local parameters.

A major difficulty of outputting 2d location info is that many of the solver routines cannot differentiate between 2d and 3d systems and multiprocessor status, so a separate location print routine is needed that can pull in the mesh type etc to provide _global_ nodeids and location info.

Please consider these comments.

John

Hello John

The conditionning of the final matrix to resolve in the resolution of the K-eps algorihtm depends on lots of critirea and can not be linked to a single parameter. Actually, one important criteria is the implicitation/explictation of source terms. In Telemac-3D, we have chosen to impplicit a part of these terms and let the others explicit and for sure, this will have a direct influence on the solver efficiency.
Actually the use of the k-eps for 3D highly unisotropic models like the one in Telemac-3D on lakes and estuary is, itself questionable. That's why we can not expect a perfect behaving of this model especially in the vertical direction, for all applications.
If you want to change some hardcoded values in the source terms, you can have a look on the subroutine soukep.f (sources/telemac3d).
Personnally, I prefer the use of GMRES solver (option 7) which I consider more robust that CG while it is tightly linked the number of bases in the Krylov subspace (keyword OPTION OF SOLVER FOR DIFFUSION OF K-EPSILON) which can be increased if we see bad convergence.

I hope that this helps

with my best regards

Riadh