From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Apr 07 2020 - 13:23:14 CDT

Vlad,
  I've got the link but hadn't actually downloaded it yet. I'll do it today.

That was the weekend we started lockdown here in Illinois, and I'm still
catching up on things. Yesterday I actually had to get special permission
to enter my building / office and fetch a Mac test machine so I can make
MacOS X builds for Catalina! Crazy times.

Best,
  John

On Tue, Apr 07, 2020 at 08:11:39PM +0200, Vlad Cojocaru wrote:
> Hi John,
>
> I was wondering whether you received my example trajectory for
> tackling this issue ... I sent it some time ago via cryptshare.
> The issue is not urgent at all, so no worries .. I am just asking to
> see if you received those files (I believe they will expire at some
> point)...
>
> Stay safe
> Vlad
>
> On 2020-01-06 21:20, John Stone wrote:
> >Hi,
> > I haven't seen any further discussion of this issue since December 19th.
> >
> >If there's any interest in actually resolving the problem, I will need
> >an example file that I can use to reproduce the behavior that Vlad
> >has reported. Vlad, can you (or anyone else) provide one?
> >
> >Best regards,
> > John Stone
> > vmd_at_ks.uiuc.edu
> >
> >On Thu, Dec 19, 2019 at 08:22:10AM -0600, John Stone wrote:
> >>Hi,
> >> Newer VMD 1.9.4 alpha builds include HDF5, whereas older revs did not.
> >>
> >>It seems possible that we're observing an issue where the HDF5 version of
> >>NetCDF (or some shared internal routines used therein) is being picked
> >>up rather than the old standalone NetCDF I compiled from source,
> >>which is what was used for all prior builds.
> >>
> >>Vlad, I'm about to be offline for 2.5 days due to travel without network
> >>access, but once I'm back in civilization, if you can post an affected
> >>NetCDF file(s) that I can use for testing, I should be able to chase down
> >>if this is caused by linking with HDF5 libs or if something less
> >>obvious might be happening.
> >>
> >>Best,
> >> John
> >>
> >>On Thu, Dec 19, 2019 at 02:09:50PM +0100, Luthaf wrote:
> >>>Hi Vlad,
> >>>
> >>>What you are seeing is an assertion inside the netcdf library: https://github.com/Unidata/netcdf-c/blob/3acf69c6a01c9964532d85d9ec8a22acd6ca2488/libsrc/putget.m4#L821
> >>>
> >>>So either the the netcdf **library** version changed, or is was
> >>>compiled without assertions (-DNDEBUG) for 1.9.4a12, and with
> >>>assertions for 1.9.4a38.
> >>>
> >>>Anyway, hitting an assertion in the netcdf library might indicate
> >>>that the files you have are invalid netcdf files. Are you able to
> >>>open them outside of vmd? For example, using `ncdump file.nc`?
> >>>
> >>>Best,
> >>>Guillaume
> >>>
> >>>Vlad Cojocaru a écrit le 19.12.19 à 10:46 :
> >>>>Well, the only thing I can say at this point is that vmd 1.9.4a12
> >>>>reads the trajectories perfectly, whereas vmd 1.9.4a38 does not
> >>>>and gives the error I reported. First I thought its one trajectory
> >>>>that is corrupted but then I checked it with other programs and it
> >>>>was fine. After that I realized that the a38 version of vmd does
> >>>>not ready any other netcdf trajectory I have ...
> >>>>
> >>>>Except the VMD version, I have not changed anything to the system ...
> >>>>
> >>>>I will look further into it and see if I can figure out what is
> >>>>happening.
> >>>>
> >>>>Best,
> >>>>Vlad
> >>>>
> >>>>On 12/18/19 5:19 PM, John Stone wrote:
> >>>>>Vlad,
> >>>>>   The only change to the NetCDF plugin (since 2016 actually) has been
> >>>>>to correct a memory leak for a cell angles unit string in the AMBER
> >>>>>reader code, nothing that would impact the eror you reported:
> >>>>>
> >>>>>@@ -133,6 +133,9 @@
> >>>>>     if (cdf->amber.cell_lengths_units)
> >>>>>       free(cdf->amber.cell_lengths_units);
> >>>>>+  if (cdf->amber.cell_angles_units)
> >>>>>+    free(cdf->amber.cell_angles_units);
> >>>>>+
> >>>>>     /* MMTK stuff */
> >>>>>     if (cdf->mmtk.comment)
> >>>>>       free(cdf->mmtk.comment);
> >>>>>@@ -1121,7 +1124,7 @@
> >>>>>     plugin.prettyname = "NetCDF (AMBER, MMTK)";
> >>>>>     plugin.author = "Konrad Hinsen, John Stone";
> >>>>>     plugin.majorv = 1;
> >>>>>-  plugin.minorv = 1;
> >>>>>+  plugin.minorv = 2;
> >>>>>     plugin.is_reentrant = VMDPLUGIN_THREADSAFE;
> >>>>>     plugin.filename_extension = "nc,ncrst";
> >>>>>     plugin.open_file_read = open_cdf_read;
> >>>>>
> >>>>>
> >>>>>I expect that the problem you're seeing is something deeper in
> >>>>>the NetCDF library itself.
> >>>>>
> >>>>>Best,
> >>>>>    John Stone
> >>>>>
> >>>>>On Wed, Dec 18, 2019 at 02:25:11PM +0100, Vlad Cojocaru wrote:
> >>>>>>Dear all,
> >>>>>>
> >>>>>>Did VMD change the netcdf plugin between version 1.9.4a12 and
> >>>>>>1.9.4a38 ?
> >>>>>>I am using netcdf trajectories created with CPPTRAJ program from
> >>>>>>AmberTools 19.
> >>>>>>
> >>>>>>When I load these trajectories in VMD 1.9.4a12, everything
> >>>>>>works well ....
> >>>>>>
> >>>>>>However, with VMD 1.9.4a38, I cannot load exactly the same
> >>>>>>trajectories loaded correctly with the a12 version. I am getting the
> >>>>>>error below. I will revert for now to the a12 version, but maybe
> >>>>>>this is worth investigating.
> >>>>>>
> >>>>>>Best wishes
> >>>>>>Vlad
> >>>>>>
> >>>>>>netcdfplugin) conventions: 'AMBER'
> >>>>>>netcdfplugin) trajectory follows AMBER conventions version '1.0'
> >>>>>>netcdfplugin) AMBER: program 'cpptraj'
> >>>>>>netcdfplugin) AMBER: program version 'V18.01'
> >>>>>>netcdfplugin) AMBER: title 'Cpptraj Generated trajectory'
> >>>>>>netcdfplugin) AMBER: application 'AMBER'
> >>>>>>netcdfplugin) AMBER: spatial dimension: 3
> >>>>>>netcdfplugin) AMBER: atom dimension: 13042
> >>>>>>netcdfplugin) AMBER: frame dimension: 80000
> >>>>>>netcdfplugin) AMBER: coordinates units: 'angstrom'
> >>>>>>netcdfplugin) AMBER: no coordinates scalefactor attribute, 1.0 assumed
> >>>>>>netcdfplugin) AMBER: coordinates scalefactor: 1.000000
> >>>>>>netcdfplugin) AMBER trajectory contains periodic cell information
> >>>>>>netcdfplugin) AMBER: cell lengths units: 'angstrom'
> >>>>>>netcdfplugin) AMBER: no cell lengths scalefactor attribute, 1.0 assumed
> >>>>>>netcdfplugin) AMBER: cell lengths scalefactor: 1.000000
> >>>>>>netcdfplugin) AMBER: cell angles units: 'degree'
> >>>>>>netcdfplugin) AMBER: no cell angles scalefactor attribute, 1.0 assumed
> >>>>>>netcdfplugin) AMBER: cell angles scalefactor: 1.000000
> >>>>>>Info) Using plugin netcdf for coordinates from file ../test.ncdf
> >>>>>>vmd_LINUXAMD64: putget.c:3593: getNCvx_float_float: Assertion `value
> >>>>>>!= ((void *)0)' failed.
> >>>>>>Abort (core dumped)
> >>>>>>
> >>>>>>--
> >>>>>>Vlad Cojocaru, PD (Habil.), Ph.D.
> >>>>>>-----------------------------------------------
> >>>>>>Project Group Leader
> >>>>>>Department of Cell and Developmental Biology
> >>>>>>Max Planck Institute for Molecular Biomedicine
> >>>>>>Röntgenstrasse 20, 48149 Münster, Germany
> >>>>>>-----------------------------------------------
> >>>>>>Tel: +49-251-70365-324; Fax: +49-251-70365-399
> >>>>>>Email: vlad.cojocaru[at]mpi-muenster.mpg.de
> >>>>>>http://www.mpi-muenster.mpg.de/43241/cojocaru
> >>--
> >>NIH Center for Macromolecular Modeling and Bioinformatics
> >>Beckman Institute for Advanced Science and Technology
> >>University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> >>http://www.ks.uiuc.edu/~johns/ Phone: 217-244-3349
> >>http://www.ks.uiuc.edu/Research/vmd/
>
> --
> Vlad Cojocaru, PD (Habil.), Ph.D.
> -----------------------------------------------
> Project Group Leader
> Department of Cell and Developmental Biology
> Max Planck Institute for Molecular Biomedicine
> Röntgenstrasse 20, 48149 Münster, Germany
> -----------------------------------------------
> Tel: +49-251-70365-324; Fax: +49-251-70365-399
> Email: vlad.cojocaru[at]mpi-muenster.mpg.de
> http://www.mpi-muenster.mpg.de/43241/cojocaru

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/