luthaf / jumos.jl Goto Github PK

We should check for positive temperature and other parameters when creating a new Thermostat (as subtype of Control).

Another meta-issue about thermostating and barostating the system. There are two ways to do this :

Enforcing the parameters after the integration

This can be done by modifying the current frame after the integration has been performed

• Velocity rescaling thermostat
• Andersen thermostat
• Berendsen thermostat

Using a custom integrator

• Berendsen barostat
• Nose-Hoover barostat/thermostat
• Chains of Nose-Hoover barostat/thermostat

Hi @Luthaf , I'm a developer of python packages for computational chemistry and, just like you I was looking into julia and rust for high performance candidates for some tasks (such as molecular simulation).

I've seen you're abandoning julia for rust, why didn't julia satisfy your requirements? I'm asking because I'd like to find out before starting porting some tools in julia.

Thanks

Meta-issue about long-range potentials computations. As far as I know, there are two main ways to do this :

• Ewalds summation
• PPPM base computations

All the simulation steps have full access to the MolecularDynamic object. Is this needed ?

This make more difficult the extension with new Enforce, Compute, ... because the user needs to know a lot about the internal representation of a MolecularDynamic object.

Just FYI, your package was identified as a user of the countlines function in Base. A breaking change was merged today where the behavior going forward will count empty lines (as opposed to the old behavior of skipping them).

Ref: JuliaLang/julia#11947

The new topology.atom_types whould make it easier to check if the requested atoms does exist in the topology, and can speedup the lookup in RDF computations

VMD style selections name He and x > 3 are very nice, and should be added to the Topology. Something like

macro s_str
    # Lot of magic here
end

top = Topology(...)

select = get_atoms(top, s"name He and x>3")
# Here select should be some kind of Vector{Bool}

I should wrap Chemharp to Julia, and use it to replace the Trajectories module.

I can wrap the C interface or the C++ interface here. I should have a look to Clang.jl for automatic wrapping.

An "append" mode should be provided for the outputs, in order to write additional data to the same file in separated runs.

We have to find a way to make it easy to use stuff from Analysis in the Simulation.

It would be great to have a Propagator type, with the following subtypes :

• MolecularDynamic
• Replay (the current interface for read/write the trajectories)
• Minimisation with it's own subtypes :
  • Gradient descent ;
  • Any other useful minimisation algorithm

like in this software : http://www.pierrehirel.info/codes/atomsk/en/option_rebox.html

Since info and warn now uses an io first parameter, this can be done easily.

Having input files with a nice syntax would be great. The YAML format seems to be a good format for this, and there is already a Julia parser. This can be a syntax example :

simulation:
    type: MolecularDynamic
    integrator:
        type: Verlet
        timestep: 1.0
    forces:
        # TODO
    controls:
        - type: BerendsenThermostat
          coupling: 100
          temperature: 450
        - type: BerendsenBarostat
          coupling: 100
          pressure: 1.4
    outputs:
        - type: TrajectoryOutput
          frequency: 10
          file: output.xyz
        - type: EnergyOutput
          frequency: 50
          file: Energy.dat
potentials:
    from_file: ../potentials.yml
initial_setup:
    cell: [10.0, 10.0, 10.0]
    # cell: {type: orthorombic, size: [10.0]}
    positions: initial.xyz
    velocities: # if needed
    topology: # if needed

The file potentials.yml looks like this :

pairs:
    - atoms: [He, He]
      type: LennardJones
      sigma: 3.4
      epsilon: 0.45
    - atoms: [*, *]  # Default values
      type: LennardJones
      sigma: 2.5
      epsilon: 0.8
      cutoff: 8.5
angles:
    - atoms: [He, Ar, Xe]
      form: HarmonicAngles
      k: 67
      theta0: 120

The implementation could build and bind the corresponding types at runtime.

Because there is no tracking of the units in the code, the with_unit function is very buggy :

julia> with_unit(45, mJ)
    188280.0 kg m²/s²

julia> with_unit(45, J)
    188280.0 kg m²/s²

See this gist : https://gist.github.com/Luthaf/a30fae741ed9f937a97b

The output on my machine :

Relative difference: 0.0030037844682750453
Direct computing
elapsed time: 1.238753331 seconds (320000000 bytes allocated, 10.19% gc time)
Table lookup
elapsed time: 0.195861645 seconds (0 bytes allocated)

The coverage is only 55% today, this should be improved up to 90% at least.

This is a meta issue about analysis capacities. Here is a Santa Claus list:

• Hydrogen Bond analysis
• Calculating root mean square quantities
• Correlation functions, and some dynamical properties:
  • Diffusion coefficient
  • Viscosity
  • Vibrational spectra

To speedup the computation. See http://en.wikipedia.org/wiki/Verlet_list. This would have to be implemented as a ForceComputer subtype.

This is a meta-issue about potentials, the code would need a lot of them :

Short range

• Morse potential

Biochem potentials

• CHARMM
• AMBER

Bonds

• harmonic

Angles

• harmonic
• cosine - harmonic

Dihedral angles

• Torsion
• Cosine series

The potential interface should also change to take a vector between two, three or four points and return a vector of the force or the energy.