Donald Robinson

Modified format to print metric units properly

/metric/base/evldx.f - reconcile with /base; update acorn calculation and SPMCDBH filter for Curtis RD method

Due to the USA long weekend, there may not be a timely response today. I hope this response helps, even if it isn't fully satisfying. The FVS staff are currently working to port the SourceForge repository to GitHub. That may be the reason you are not seeing a patch in the SourceForge repo, even though the date may be updated. My understanding is that as soon as the port is complete (in the next week or so) the Summer 2022 release will be available and current, in GitHub. Hopefully the fix will be...

Due to the USA long weekend, there may not be a timely response today. I hope this helps. The FVS staff are currently working to port the SourceForge repository to GitHub. That may be the reason you are not seeing a patch in the SourceForge repo, even though the date may be updated. My understanding is that as soon as the port is complete (in the next week or so) the Summer 2022 release will be available and current, in GitHub. Hopefully the fix will be present in the new release.

/metric/base/evldx.f

Correction of variable used in logical comparison. Was using QMD by mistake.

This kind of math bug might mean that the routine has not been exercised over a broad range of inputs and species. I know that the R-tools Fortran compiler is less forgiving than the Intel compiler, but it is the standard compiler for FVS. I think that changing to double precision isn't the first thing to try. If I were in your place I'd pull apart the equation (which you did) and then see if you can choose a lower bound on the input value that will not break when passed to exp(). You could compute...

This kind of math bug might mean that the routine has not been exercised over a broad range of inputs and species. I know that the R-tools Fortran compiler is less forgiving than the Intel compiler, but it is the standard compiler for FVS. I think that changing to double precision isn't the first thing to try. If I were in your place I'd pull apart the equation (which you did) and then see if you can choose a lower bound on the input value that will not break the behaviour. You could compute it in...