[Gfs-devel] Coding issues wrt gfsriver and gfsourcepipe

[George Gerber]

Hi all,
I have developed an improved testcase for the culvert module. This has led me to the following 2 issues which i would appreciate comment on:
1) in river.h the gfssourcepipe structure is defined, which makes use of the h1 and h2 variables. My understanding is that these variables represent the flow depths at the endpoints of the conceptual pipe; that they are obtained from the solver and that they can in some cases assume negative values. In an earlier patch i forced these variables to be positive using fabs(), because a floating point exception would occur when the pow(h1, 1.5) function was later called in the code. I see that the latest source code has removed/relaxed this constraint. Maybe someone with a better understanding of the solver algorithm can advise as to how to properly deal with negative flow depths (h values)?
2) in river.h the gfssourcepipe structure defines h as the flow depth. In gfsriver the variable p typically represents the flow depth, while h represents the flow head (=bed elevation+flow depth). There therefore appears to be a variable naming clash. In english hydraulic texts y traditionally represents flow depth, h head, z bed elevation, p pressure etc. Should the gfssourcepipe structure in gfsriver.h not refer to p (flow depth as defined in gerris)?

Best regards,
George

[Stephane Popinet]

Hi George,

> 1) In an earlier patch i forced these variables to be positive using

> fabs(), because a floating point exception would occur when the pow(h1,
> 1.5) function was later called in the code. I see that the latest source
> code has removed/relaxed this constraint. Maybe someone with a better
> understanding of the solver algorithm can advise as to how to properly deal
> with negative flow depths (h values)?

It is clearly inconsistent to have negative water depths. If this
happens, this points to a problem "upstream" of the culvert module and
so should be fixed there rather than "hiding" the problem by taking
the absolute value (which is also clearly inconsistent).

I can't remember precisely but this may be what I have done in the current code.

Do you have an example where you get negative values (ans thus
crashes) with the current code?

> 2) in river.h the gfssourcepipe structure defines h as the flow depth. In
> gfsriver the variable p typically represents the flow depth, while h
> represents the flow head (=bed elevation+flow depth). There therefore
> appears to be a variable naming clash. In english hydraulic texts y
> traditionally represents flow depth, h head, z bed elevation, p pressure
> etc. Should the gfssourcepipe structure in gfsriver.h not refer to p (flow
> depth as defined in gerris)?

Variable names are a matter of convention and (unfortunately?)
conventions vary. I believe the variable names in "SourcePipe" and the
culvert module follow those used by Boyd, 1984, which are different
from the "english hydraulic texts" conventions you mention, and also
different from the conventions in Gerris...

cheers

Stephane

------------------------------------------------------------------------------
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612
_______________________________________________
Gfs-devel mailing list
Gfs-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-devel

[George Gerber]

Hi Stephane,

I have sent 4 patches using darcs. Only two of them are relevant (those of 1 Jan 2013). The other older 2 patches can be ignored (I could not deselect the 2 older patches when running 'darcs send').
I have also attached the shell script and gfs case file to this email in which a floating point error occurs, due to the negative flow depth provided by the solver.

The first part of the shell script calls the discharge_table executable, which generates a table of culvert discharges for various upstream and downstream flow depths and then plots the results. This part can be ignored/deleted.

The second part of the shell script executes gerris2d and this causes a floating point error on my machine (in the first run of the for-loop due to -0.00, but I have also encountered negative numbers during other tests).

Please let me know if you require any further info.

Best regards,
George

[Stephane Popinet]

Hi George,

> I have sent 4 patches using darcs. Only two of them are relevant (those of 1
> Jan 2013). The other older 2 patches can be ignored (I could not deselect
> the 2 older patches when running 'darcs send').

Thanks for the patches, however if you "cannot deselect the 2 older
patches" in darcs, it means that the more recent patches are dependent
on these older patches i.e. it is not possible to apply only the more
recent patches. We have two options:

1) apply all your patches: what are the older patches doing? are they
unecessary/problematic?

2) you need to "unpull" all the (4) dependent patches (in a new darcs
repo), manually copy the changes corresponding only to the two recent
patches, then redo fresh patches (which will then not be dependent on
the older changes).

> I have also attached the shell script and gfs case file to this email in
> which a floating point error occurs, due to the negative flow depth provided
> by the solver.

OK. I will have a look.

[Stephane Popinet]

Hi George,

I attach the following two patches which should fix the "negative
water depth" issue. It had to be fixed upstream of the culvert module,
in SourcePipe.

Thu Jan 10 12:33:34 NZDT 2013 Stephane Popinet <s.po...@gmail.com>
* Fixes for convergence checks for Boyd's culvert model

Thu Jan 10 12:33:58 NZDT 2013 Stephane Popinet <s.po...@gmail.com>
* Checks that SourcePipe does not use negative water depths

Have a look and tell me if that looks OK to you.

cheers

Stephane

[George Gerber]

Hi Stephane,

I have applied your patch and based on it rewritten my code corrections and resubmitted them as a new patch.
Unfortunately, I still run into a floating point error when the solver provides me with a -0.00.
I have attached the testcase to this file. I am not sure if it is a mistake on my side.

Best regards,
G