Hello,
I would be interested to know if anyone has implemented successfully in GAIA the predictive bed roughness approach (in ride_vr.f), based on [name removed] empirical scheme, which worked correctly in Sisyphe, feeding roughness back to T2D as a run proceeded. Using v9.0.0, the addition of BED ROUGHNESS PREDICTOR OPTION = 3 to the GAIA cas file has no effect, i.e. the coupled scheme runs, but produces the same output as for the default (i.e. BED ROUGHNESS PREDICTOR OPTION = 1). Adding instead, COMPUTE BED ROUGHNESS AT SEDIMENT SCALE = YES
BED ROUGHNESS PREDICTOR OPTION = 3
SKIN FRICTION CORRECTION = 2
the program crashes at the first timestep.
Has anyone else encountered this behaviour? Am I missing a keyword??!
Many thanks,
[name removed]
Dear [name removed],
we have used the bed roughness predictor (COMPUTE BED ROUGHNESS AT SEDIMENT SCALE=YES => KSCALC) in version 8.2 with gaia successfully. I tried that project also in v9p1 and it worked as well. But we used the default value for the SKIN FRICTION CORRECTION (=1). So I guess that KSR might be the problem.
What I have seen from a short look at the source is, that the ripple roughness (KSR) will only be calculated if KSCALC=YES (see tob_gaia.f). So in case you want have telemac the determined value and gaia a value calculated from dm and ripples it will not calculate the ripples. SKIN FRICTION CORRECTION 1 and 2 will do the same (as you already found out).
If you want to have the same roughness coefficient in gaia and telemac, there is no need for a skin friction correction, because the formula will be chosen with BED ROUGHNESS PREDICTOR OPTION. I tested my example with skin friction correction=2 and kscalc and had no crash. But it produces different results depending on the skin friction correction which I don’t find plausible. I think in case of kscalc MU should be 1, so that the roughness coefficient is the same for telemac and gaia.
I think that you discovered at least 2 bugs…
Do you want to fix it yourself? Or should me or someone else try to fix it? I think it is not complicated to fix the fortran. But it would be nice to have an example which worked earlier (with sisyphe or comparison to measurements). I checked, there is no gaia example with bed roughness predictor. So maybe it is a good time to add one.
[name removed]
1 Like
Hi [name removed],
It’s very good to have your interest/involvement in this topic and thank you for your detailed response to my query.
You may be right that there is a bug somewhere within tob_gaia.f. In sisyphe, with BED ROUGHNESS PREDICTION=YES => KSPRED, there was an error in tob_sisyphe.f in releases up to at least v7p3 which prevented predicted ks values being fed back into t2d as required. Following the first CALL COEFRO_SISYPHE, the command CALL OS('X=[name removed], X=KS_TEL, Y=KS) needed to be replaced by CALL OV( 'X=Y ', [name removed], KS%R, KS%R, 0.D0, NPOIN) in order to remove the error. This change had been corrected by the time of release v8p2 allowing dune+megaripple+ripple ks to be returned to t2d.
However the procedure in tob_gaia.f appears to have been modified somewhat compared with that in tob_sisyphe.f and so, if you are able to spot what might be going on, I would be very grateful!
There is one further, separate point to add related to ride_vr.f. Where megaripple roughness KSCMR is concerned, there has been a long-term error in the code through earlier releases, up to and including 9.0, which should be corrected as follows:
CCorrecting error in KSCMR22jun2012**************
C KSCMR=0.00002D0FFSHN(I)(1.D0-EXP(-0.05D0MOB))
KSCMR=0.00002D0*FFS*HN(I)*(1.D0-EXP(-0.05D0*MOB))
&*(550.D0-MOB)
C************************************************************
If I can supply any more details that might help, please let me know either here or by email, and I’ll let you know of any progress that I might make.
Best wishes,
[name removed]