- removed comment
GRHydro ReconstructPolytype.F90 passes wrong arguments to SimplePPM(M)_1d
Zach Etienne found (last year on August already) that
In GRHydro_ReconstructPoly.F90, notice that after gzz in the SimplePPM_1d() and SimplePPM_1dM() function calls, psi4 is passed. However, if you look at the SimplePPM_1d() and SimplePPM_1dM() routines (within GRHydro_PPM.F90), you will find that psi4 is not a variable in the function call list, and beta^i should come after gzz, for flux_direction i.
Pull request https://bitbucket.org/einsteintoolkit/einsteinevolve/pull-request/6/fix-usage-of-psi4-in-polytype/diff fixes this.
Keyword: GRHydro
Comments (4)
-
-
reporter - removed comment
These routines should eventually be removed in favor for the C++ code, yes. Using interfaces would have been nice, however I find them to be less useful then in C since there is no way to enforce that the interface declaration eg in a file GRHydro_Interfaces.h90 matches the actual definition in say GRHydro_Prim2Con.F90 since one cannot include the interface block in the subroutine whose interface is described. Ie.
subroutine foo(bar) implicit none real bar interface subroutine foo(bar) implicit none real bar end subroutine end interface write (*,*) "Got you" end subroutine
is actually not allowed in Fortran (and the compilers abort). A module would enforce consistency but then one cannot have multiple subroutines from different files in the same module it seems.
Thank you. Applied as git hash d5b504bfffacc546d11664d4c9677f67bc835ace and b5c883fe647d380d6555f9614310920888027f4e of GRHydro.
-
reporter - changed status to resolved
- removed comment
-
reporter - changed status to closed
- edited description
- Log in to comment
Looks good to me. Using interfaces would have been a good idea back then - but then we are going to remove these anyway, aren't we?