jeffmm / simcore Goto Github PK

What is needed?
Anisotropic springs for asymmetric compressive and stretched spring constants.

Feature implementation
Add optional second lookup table for each crosslink calculated with a second spring constant for compressed spring forces and check for anisotropic_spring_flag to implement asymmetric spring forces.

Additional context
Simcore currently throws warning when anisotropic spring flag is true to let user know that feature is unimplemented.

Describe the issue
Sometimes filaments don't render for some reason (maybe <1%)

To Reproduce
Run simulation of many filaments as well as motors, see that occasionally motors bind to filament shaped objects (that are even active if driving_factor > 0) but no filament is there

Context
Ran with polydispersity, packing_fraction: 0.05, draw_type: fixed

Describe the issue
static_particle_number flag being set to true will prevent interactions from initializing properly after reloading a simulation

To Reproduce
Reload a simulation with static_particle_number = true, check if filaments interact

Expected behavior
Interaction manager should be smart enough to know to load interactor objects at simulation initialization despite static particle number flag

I'm thinking of adding this tool to prevent git from tracking notebook outputs in the future: https://github.com/kynan/nbstripout

We can also remove outputs from the Jupyter notebooks from git history, since that is where the majority of the bloat of the repo comes from. This can be done using git filter-branch as described in the nbstripout repo.

Describe the issue
Trying to reduce a spec file using the -R flag with simcore.exe causes error: YAML::TypedBadConversion<int>

To Reproduce
simcore.exe -R [n] test_params.yaml

Expected behavior
Inputs are read in and written with a factor of n reduced time resolution

Additional context
Run on my laptop, but likely an issue on the docker image as well, likely due to the yaml-cpp upgrade which recognized booleans and does not like to interchange booleans and ints.

What is needed?
A standard way to apply clang-format to the project to prevent different fixer plugins from reformatting the code all the time and leading to annoying code reviews.

Feature implementation
I think we just add a file somewhere that lists the formatting options so that the plugins can find it. Probably an easy fix.

What is needed?
There are a number of unused or abandoned git branches(including some of my own). Could we prune these to make it easier to see what is being actively worked on?

Feature implementation
Delete branches that have been abandoned from github's history.

Additional context
Only delete branches if you know for sure no one is using them. We could talk about this briefly at the next code review.

Describe the issue
If a previous run's output files were cut off due to time limits, early termination, etc, running a post-processing run on the outputs succeeds, but occasionally crashes after reaching input EOF

To Reproduce
Run a simulation that generates spec files, preferably one in which the I/O from the specs takes a good deal of time, then CTRL+C. There will be a chance or that attempting to create a movie or post-analysis with the -a or -m flags will lead to a crash after reaching the spec file's EOF.

Expected behavior
Same simulation behavior, minus the crash. The simulation is supposed to have a soft-exit condition when it detects an unexpected EOF, but this seems to only occasionally work.

Additional context
So far, this hasn't affected the ability to create movies or do analysis

In order for CI to work as intended, we either need to create a new Dockerfile that uses an environment variable set by travis to pull the current branch so travis will test that rather than master each time. Otherwise builds for non-master branches are redundant and unhelpful, and won't tell us whether anything is broken.

Alternatively, I can configure travis to build the current branch in its own linux environment that mirrors the Docker environment, and trust that the Docker build will work as expected.

Describe the issue
Trying to run simcore.exe with the -l flag and checkpoint_flag=false results in failing to find the .checkpoint file, even if it is there.

To Reproduce
simcore.exe -l some_run.yaml with checkpoint_flag=false and the associated some_run_filament_mt.checkpoint file in the same directory. The reload works fine with checkpoint_flag=true

Expected behavior
checkpoint_flag should only correspond to whether or not future checkpoints are generated, not whether we can load previous checkpoints

Describe the issue
Singularity Hub doesn't seem to be respecting github's webook to indicate rebuilding simcore's singularity image

To Reproduce
Push a commit to master or experimental branches, watch singularity hub decline to do its job

Expected behavior
Singularity hub should rebuild the simcore singularity image from the recipe on both master and jmm/directory_tree_refactor branches when commits to the branches are made

Additional context
This may be due to singularity hub caching the Singularity recipe and not updating if it doesn't see any change, so merging jmm/directory_tree_refactor or seeing an additional recipe for an experimental image (e.g. Singularity.experimental) might force a rebuild.

In the meantime, my workaround has been to build the singularity image on summit using
singularity remote login
which gives a link that will let you log in with your github, then generate a key, then use the key to login, then you can build remotely with
singularity build --remote simcore_experimental.sif Singularity
(you have to do a remote build, because doing a singularity build requires sudo)

What is needed?
Ability to check latest commit that was used to compile simcore from the command line with a version flag.

Feature implementation
Use a hook from CMake or similar to embed either the git tag or more likely the current commit's hash/date so that simcore.exe --version or simcore.exe -v will let the user know whether they are using the most recent version.

Additional context
This has come up a few times for me on summit, where I have several compiled binaries of simcore running in different folders, and maybe I update one or two of them to add some experimental features or analysis, and then I lose track of whether the binary in the current folder is up to date, etc. Being able to run this in a container would be useful as well to ensure that the image is up to date: e.g. docker run --rm -it jeffmm/simcore simcore.exe --version