On Sun, Mar 14, 2021, Charo del Genio wrote:
>Very alarmingly, in two
>specific files, some rows are too long and get truncated by the
>fortran compiler. The two files in question are wlesprm.F, in rows
>24-26, and resp.F at row 1207.
You are correct, but I'll note that nothing will change. The wlesprm
routine can never be called: this was a part of a decades-old and
never-finished attempt to use LES and old-style perturbation together.
That code path is disabled, but a cleanup is still needed.
(Carlos: does it make sense to deep-six the "lespert" option? I'm using LES
again, so getting some code cleanup would make sense. Note that the
original code would still be in git, just not complicating the code most
users would see.)
It looks like the variable in resp.F is never used. But it's still helpful
to have people looking at the codes, so thanks.
[Developers: does someone want to work on resp functionality? We have at
least four codes that seem to do this, resp.F, mdgx, py_resp and
resp_fitting.py.]
>Finally, I'm attaching the three RXSGLD patches as a single file, as
>requested. The patch can be applied from the root of the AmberTools
>source directory, as should be clear upon inspection. If I remember
>correctly, Xiongwu (CCed on this email) checked them and said they
>were OK, but I will defer to him for confirmation.
Thanks. I've submitted these as a merge request for AmberTools21.
Apologies that this kind of fell through the cracks earlier: we didn't have
a clear idea of who was actually going to do this.
Thanks again for your help. As I said, let me know if you'd like to see the
development version. Especially for gcc10, lots of changes have already
been made there, but we don't yet have complete success. There seem to be
some conflicting reports about whether turning off optimization works or
not.
....dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Mar 14 2021 - 13:30:02 PDT
