I'm getting some odd trajectories after running the trajectory editor with default values so no changes to the trajectory should occur. I'm using the NAMD dmpc_in_water trajectory.

Before

After (this branch)

After (protos)

COM trajectory to work well and analysis calculation with COM trajectory also seems to be working fine.

Just a few things about COM atoms and the 3D viewer. I ran the the COM trajectory on the discover cubane/buckyball system.

the atom radii are maybe too big? We also need to block the bonding between COM atoms similarly to dummy atoms, here is what I see when I set a smaller atom radius.

We also need to think about what the radius setting should mean exactly because it could mean vdw radii or covalent radii or something else.

In the end I decided to define the radius of a COM atom as the SUM of two terms:

1. the mass-weighted average of the atom distances from the centre of mass,
2. the mean covalent radius of the atoms in the groups.
   The atom size scaling is still less than 1 (0.4 by default, so atoms don't block the view). If I change the atom scaling to 1.0, for the fullerene/cubane system I get the picture above.

I'm getting some odd trajectories after running the trajectory editor with default values so no changes to the trajectory should occur. I'm using the NAMD dmpc_in_water trajectory.

Two problems had to be addressed:

1. MinimalPDBReader was grouping molecules wrong, adding a water molecule to a chain,
2. contiguous_configuration normally shifts atoms to minimise their distance from the first atom in the group. I added an option to group them around the centre of the group instead. (Not the centre of mass, just the geometric centre). For now I made TrajectoryEditor use that option, as it is less likely to break long chains. We can discuss if we should always use this option or not. For now I left it as "false" to stay compatible with the old code.
   If you convert the trajectory again and run a null trajectory editor, nothing should change.

I'm not sure how this happened since the PDF function is the same on protos and this branch but there are some issues wth the SSF calculation on this branch. This worked before, I think d500f10 should be the first bad commit.

I'm not sure how this happened since the PDF function is the same on protos and this branch but there are some issues wth the SSF calculation on this branch. This worked before, I think d500f10 should be the first bad commit.

I completely missed that SSF also inherits from DistanceHistogram. PDF needed a change of one scaling factor in this PR. Now SSF has it too. For the trajectories I checked, the results matched those from protos.

Some differences between the RMSD results on protos and this branch.

Also the RMSD calculation is quite a bit slower on this branch.

RMSF job on this branch does not give the correct number of data points with the DFTB water trajectory and the molecule group selection.

On this branch there are only two data points, there should be 100 since there are 300 atoms. Also even with the atom group selection the results are different.

Here is the EISF for the VASP trajectory, protos and this branch produce the same results.

Here is the EISF for the DFTB trajectory, protos and this branch produce different results.

I made sure the set the seed to 1 so they should generate the same q-vectors. I think there is some issue with trajectories with atoms that go outside of the unit cell for some calculations.

DFTB - some atoms go outside the unit cell

VASP trajectory - all atoms stay inside the unit cell

I think this is whats causing the RMSD and RMSF issues above. I used the VASP trajectory to test quite a few of the MDANSE jobs so there are probably a few more that do not work with the DFTB trajectory.

I have compared the results from protos to the current branch. It was correct for:

• EISF, DISF
• MSD atoms and molecules grouping,
• RMSD, RMSF,
• DOS, VACF, PACF
• angular correlation,
• infrared.
  DFTB water and LAMMPS CuSbS trajectories were used in the tests, since one has molecules going out of the box, and the other has clear jumps across the simulation boundary.

I think that the read_com_trajectory method in MdanseTrajectory was the main source of problems before, and it has been fixed now.

I've done some more testing and it looks like there might be some issues with loading h5md files in this branch. I'm using MDANSE\Tests\UnitTests\Data\Ar_mdmc_h5md.h5.

When I load the h5md file I also get the following error.

"KeyError: "Unable to synchronously open object (object 'chemical_system' doesn't exist)""

but it seems to continue to work anyway.

Anyway here are the following results for PACF, RMSD, and RMSF.

I've done some more testing and it looks like there might be some issues with loading h5md files in this branch. I'm using MDANSE\Tests\UnitTests\Data\Ar_mdmc_h5md.h5.

When I load the h5md file I also get the following error.

"KeyError: "Unable to synchronously open object (object 'chemical_system' doesn't exist)""

but it seems to continue to work anyway.

True, this message was not really meant to be this dramatic. Now there is just a warning that MdanseTrajectory class could not read the file, so we will try H5MD instead.

Anyway here are the following results for PACF, RMSD, and RMSF.

I corrected it, now the results match for me.

I think that all the problems you highlighted so far have been fixed in the latest version of this PR. Also, now the MDTraj converter checks for bonds in the topology files, and uses them to identify molecules.

Thanks, yes looks good as far as I can tell all the converters are working correctly now.
One bug I've noticed is that when you delete an open trajectory from the GUI, the file still appears to be locked so I can't delete or move the file in Windows. Previously we were able to do this and we can still do this with the MDA files.

Looks like this is fixed now.

This is fixed when you load an already converted trajectory but I found one more edge case. When you convert with autoload and then delete it from the GUI the trajectory file is still locked so it can't be deleted or moved.

This is fixed when you load an already converted trajectory but I found one more edge case. When you convert with autoload and then delete it from the GUI the trajectory file is still locked so it can't be deleted or moved.

When does it go away? Do you have to switch off the GUI, or is it enough just to wait?

As far as I know this issue is Windows-specific.