malramsay64 / crystal-packing Goto Github PK

stdweb is unmaintained

The author of the stdweb crate is unresponsive.

Maintained alternatives:

• wasm-bindgen
• js-sys
• web-sys

See advisory page for additional details.

There should be the ability to run a search from a given configuration attempting to
find the minima.

It should be relatively simple to output a configuration which is relatively portable so
that it can be re-loaded or analysed.

There is a regression of about 10% when running the shape creation benchmark when
switching to using the matrix for transformations.

There should be an initial step which generates the starting configurations for each MC minimisation. This step should be straightforward and do a good job of sampling the space.

One idea is to do an initial minimisation with a large step size, to get close to the optimal packing, followed by the longer simulation with larger steps.

Rather than the number I have now, which is purely indicative. I should have a value of the free energy. This likely will have to be negated as a result but that is workable.

This will require some additional thought on #2 for getting reproducible results.

The best state should always be returned from the optimisation, with the initial state
checked to ensure it is valid before continuing.

To include this in the range of other projects I am using for my PhD, this should compile to a conda package which can then be easily deployed.

Rather than collecting a vector which is then iterated over, I should just return the
iterators. This should be possible using the impl Trait syntax.

Rather than displaying up to 2 unit cells surrounding the original, the visualisations should only include a single surrounding unit cell.

This may require re-working the periodic boundary code to accept a parameter taking the number of periodic images to return

The output of this configuration should be the simplest unit cell possible. It is
probably not possible to provably do this, however a best effort attempt to simplify the
generated configurations is a good idea.

One part of the simplification would be to limit the degrees of freedom available to the
cell. This approach is similar to how the wyckoff sites with symmetry elements help,
they reduce the degrees of freedom and will result in a simpler configuration.

There is also the approach of giving a small weight to a simpler configuration,
particularly at the start of the simulation which would help bias a simpler unit cell,
although there is the issue that this may bias the configuration away from the best
score.

There is currently only a single acceptance algorithm for all the different types of
scores. This is an issue in that for the acceptance criteria to work properly there
needs to be a good choice of score or a good choice of the 'temperature' for the
acceptance. This means either a good method of controlling it, values which work for a
large range or something similar.

There is an issue with how the transformations of the cells is being calculated in outputting the svg files.

Have some flag which changes when converting between coordinates so that it is not
possible to double convert or other weird things.

The alternative wyckoff sites with higher symmetry, require that the position in at least one axis is fixed as well as the orientation.

The simulation should handle fixing these parameters.

This will allow me to cite my work within my thesis

This will identify any issues with the few lines of unsafe code I am using.

One of the issues with the current unsafe blocks is the complete lack of checking for
lifetimes or the existance of the underlying pointer.

This would use a distance cutoff for the energy calculations, with any particle further
away than a specified distance not being counted. This is similar to the Shifted Lennard Jones
potential and this may need to be implemented to avoid instabilities.

The README should include at least

• Installation instructions
• Useage/getting started guide
• Description of project

I don't know exactly where the error lies, whether it is in the code for the
intersection or the visualisation, however there is a disconnect between
what the code thinks is intersecting and what the visualisations display as
intersecting.

This is particularly troublesome for the transformations with either glide planes or
mirrors. The p2 crystal appears to be fine, however the p2gg or the pg don't have the
same issues.

The (shunting-yard)[https://en.wikipedia.org/wiki/Shunting-yard_algorithm) algorithm is a general method of calculating a mathematical expression from a text input. This would handle the general case much better.

There are a number of implementations in rust

• Rosetta code
• rekka/meval-rs
• simon-whitehead/rust-yard

I will need some modifications to this algorithm since I am using it to fill values in a matrix so I don't think using an external crate is the solution.

There should be a clear indication of why the unsafe block is used, and under what conditions I am ensuring that the code is safe. This should include the assumptions I have made.

Additionally I have added the send and sync traits to the unsafe code, so these should also be explained and if possible removed.

Rather than using the definition which I currently have, which is proving to be
problematic and complicated. It is likely much simpler to just use a transformation
matrix of size N+1 where N is the dimension of the transform.

I am creating a matrix anyway so there is no real change to the input, mostly the change
will be accessing the values and how they change.

I want to work to reduce the amount of space the monte carlo algorithm searches by removing degenerate configurations. I am not entirely sure if all of these will work or reduce the space too much.

• cell xlen >= ylen, by only allowing a single orientation
• Particle x,y <= 0.5, positions in the bottom left hand corner helps with symmetry. Might need to be 1/N where N is the number of wyckoff sites.

These choices will need to be well documented and explained

This would require that the molecule is placed in the site with some additional constraints. Initially starting simple is the best path forward for this.

With the same configurations the simulations should give exactly the same result.

This is simply a case of setting the seed of the random number generator for each
optimisation from the index.

There should be tests of the cli for breaking changes. This is best done with the assert_cmd crate. https://docs.rs/assert_cmd/0.11.1/assert_cmd/

All particles are initially oriented the same direction, which doesn't result in a particularly wide range of configurations. There should be some way to initialise the orientation, whether randomly or procedurally such that this space is explored better.