mcellteam / mcell Goto Github PK

CHECKPOINT_REALTIME allows the user to specify a NOEXIT option so that the simulation continues to run after reaching the checkpoint. The same NOEXIT option should be made available for CHECKPOINT_ITERATIONS.

Branch: dynamic_meshes

Currently, the initial set of meshes are treated differently than meshes that appear later via dynamic geometry events. Those initial meshes are included in the main mdl (object definition and instantiation), whereas meshes that appear later have their geometry files listed in the dynamic geometry file. We should change this such that those initial meshes are treated just like the meshes from dynamic geometry events (i.e. the meshes should be in a separate file that is listed in the dynamic geometry file).

Here's an example of how it would work.

Previously, you would have something like this in the dynamic geometry file:

1e-05 divide.002.mdl
2e-05 divide.003.mdl
3e-05 divide.004.mdl
4e-05 divide.005.mdl
5e-05 divide.006.mdl

With this change, you would instead do this (notice the first line):

0 divide.001.mdl
1e-05 divide.002.mdl
2e-05 divide.003.mdl
3e-05 divide.004.mdl
4e-05 divide.005.mdl
5e-05 divide.006.mdl

And for the main MDL, you previously would have done something like this:

TIME_STEP = 1E-5
ITERATIONS = 152

DYNAMIC_GEOMETRY = "list_of_geometry.txt"

DEFINE_MOLECULES { vm { DIFFUSION_CONSTANT_3D = 1e-05 } }

INCLUDE_FILE = "divide.001.mdl"

INSTANTIATE Scene OBJECT {
  Icosphere OBJECT Icosphere{}
  Release_Site RELEASE_SITE {
    SHAPE = Scene.Icosphere
    MOLECULE = vm
    NUMBER_TO_RELEASE = 100
  }
}

Now, you would do this:

TIME_STEP = 1E-5
ITERATIONS = 152

DYNAMIC_GEOMETRY = "list_of_geometry.txt"

DEFINE_MOLECULES { vm { DIFFUSION_CONSTANT_3D = 1e-05 } }

INSTANTIATE Scene OBJECT {
  Release_Site RELEASE_SITE {
    SHAPE = Scene.Icosphere
    MOLECULE = vm
    NUMBER_TO_RELEASE = 100
  }
}

What is the current state of MCell?

I see there is activity in the dev branch but no new release since 2016.

FRONT, BACK, or ALL CROSSINGS/HITS don't work for surface molecules, although the QRG suggests otherwise:

For a volume molecule output the number of times the named molecule has hit the named region (or object). For a surface molecule output the number of times the named molecule hit the boundary of the named region. The hits specifier should be one of FRONT_HITS, BACK_HITS, ALL_HITS, FRONT_CROSSINGS, BACK_CROSSINGS, and ALL_CROSSINGS. For a volume molecule the meaning of these specifiers is obvious. For a surface molecule FRONT means inside out direction, and BACK means outside in direction. The count is cumulative.

Also, when I say these count statements don't work, I mean that the counts reported are all zero.

We should either fix this or print an error during parsing to indicate that this functionality isn't supported.

Here's an MDL that demonstrates this problem:

ITERATIONS = 1000
TIME_STEP = 1e-06
VACANCY_SEARCH_DISTANCE = 10

DEFINE_MOLECULES {
  sm { DIFFUSION_CONSTANT_2D = 1e-06 }
}

Plane POLYGON_LIST
{
  VERTEX_LIST
  {
    [ -0.074999988079071, -0.0899999886751175, 0 ]
    [ 0.104999989271164, -0.0899999886751175, 0 ]
    [ -0.074999988079071, 0.0899999886751175, 0 ]
    [ 0.104999989271164, 0.0899999886751175, 0 ]
    [ -0.0299999937415123, -0.0899999886751175, 0 ]
    [ 0.0599999949336052, -0.0899999886751175, 0 ]
    [ 0.0599999949336052, 0.0899999886751175, 0 ]
    [ -0.0299999937415123, 0.0899999886751175, 0 ]
    [ -0.074999988079071, 0.0449999943375587, 0 ]
    [ -0.074999988079071, -0.0449999943375587, 0 ]
    [ 0.104999989271164, -0.0449999943375587, 0 ]
    [ 0.104999989271164, 0.0449999943375587, 0 ]
    [ -0.0299999937415123, -0.0449999943375587, 0 ]
    [ -0.0299999937415123, 0.0449999943375587, 0 ]
    [ 0.0599999949336052, -0.0449999943375587, 0 ]
    [ 0.0599999949336052, 0.0449999943375587, 0 ]
  }
  ELEMENT_CONNECTIONS
  {
    [ 11, 3, 6 ]
    [ 13, 7, 2 ]
    [ 15, 6, 7 ]
    [ 5, 14, 12 ]
    [ 14, 15, 13 ]
    [ 4, 12, 9 ]
    [ 12, 13, 8 ]
    [ 1, 10, 14 ]
    [ 10, 11, 15 ]
    [ 15, 11, 6 ]
    [ 8, 13, 2 ]
    [ 13, 15, 7 ]
    [ 4, 5, 12 ]
    [ 12, 14, 13 ]
    [ 0, 4, 9 ]
    [ 9, 12, 8 ]
    [ 5, 1, 14 ]
    [ 14, 10, 15 ]
  }
  DEFINE_SURFACE_REGIONS
  {
    sr_inner
    {
      ELEMENT_LIST = [4, 13]
    }
    sr_outer
    {
      ELEMENT_LIST = [0, 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17]
    }
  }
}

INSTANTIATE Scene OBJECT {
  Plane OBJECT Plane {}
  Release_Site RELEASE_SITE {
   SHAPE = Scene.Plane[sr_inner]
   MOLECULE = sm'
   NUMBER_TO_RELEASE = 1
  }
}

REACTION_DATA_OUTPUT {
  STEP=1e-6
  {COUNT[sm,Scene.Plane[sr_outer],FRONT_HITS]}=> "./sm.sr_outer.fh.dat"
  {COUNT[sm,Scene.Plane[sr_inner],FRONT_HITS]}=> "./sm.sr_inner.fh.dat"
  {COUNT[sm,Scene.Plane[sr_outer],FRONT_CROSSINGS]}=> "./sm.sr_outer.fc.dat"
  {COUNT[sm,Scene.Plane[sr_inner],FRONT_CROSSINGS]}=> "./sm.sr_inner.fc.dat"

  {COUNT[sm,Scene.Plane[sr_outer],BACK_HITS]}=> "./sm.sr_outer.bh.dat"
  {COUNT[sm,Scene.Plane[sr_inner],BACK_HITS]}=> "./sm.sr_inner.bh.dat"
  {COUNT[sm,Scene.Plane[sr_outer],BACK_CROSSINGS]}=> "./sm.sr_outer.bc.dat"
  {COUNT[sm,Scene.Plane[sr_inner],BACK_CROSSINGS]}=> "./sm.sr_inner.bc.dat"

  {COUNT[sm,Scene.Plane[sr_outer],ALL_HITS]}=> "./sm.sr_outer.ah.dat"
  {COUNT[sm,Scene.Plane[sr_inner],ALL_HITS]}=> "./sm.sr_inner.ah.dat"
  {COUNT[sm,Scene.Plane[sr_outer],ALL_CROSSINGS]}=> "./sm.sr_outer.ac.dat"
  {COUNT[sm,Scene.Plane[sr_inner],ALL_CROSSINGS]}=> "./sm.sr_inner.ac.dat"
}

MCell should report the MDL file name and line number for all errors and warnings.

I'll update this with examples as they're discovered, but it would be good to ensure that this is done systematically so it's not handled on a case by case basis ... if possible.

A strange bug can be triggered when creating a surface class where all molecules should be absorbed (i.e. ABSORPTIVE = ALL_MOLECULES). The problem is that volume molecules are not absorbed after the first time step. This seems to require a fairly specific set of conditions to trigger. The following conditions are sufficient (and possibly necessary):

• Release both surface and volume molecules on an object
• Assign an absorptive surface class to the ALL region of the object using the ALL_MOLECULES keyword

If you make any of the following changes, the bug will not happen:

• Assign the surface class to a region which is a subset of the object (e.g. sr region is example below)
• Release only volume molecules
• Use the ALL_VOLUME_MOLECULES keyword instead of ALL_MOLECULES

Here is an example of a test that triggers the bug:

ITERATIONS = 1000
TIME_STEP = 1e-06

DEFINE_MOLECULES
{
  vm { DIFFUSION_CONSTANT_3D = 1e-06 }
  sm { DIFFUSION_CONSTANT_2D = 1e-05 }
}

DEFINE_SURFACE_CLASSES
{
  sc
  {
    /*ABSORPTIVE = ALL_VOLUME_MOLECULES;*/
    /*ABSORPTIVE = ALL_SURFACE_MOLECULES;*/
    ABSORPTIVE = ALL_MOLECULES;
  }
}

Cube POLYGON_LIST
{
  VERTEX_LIST
  {
    [  0.1,  0.1, -0.1 ]
    [  0.1, -0.1, -0.1 ]
    [ -0.1, -0.1, -0.1 ]
    [ -0.1,  0.1, -0.1 ]
    [  0.1,  0.1,  0.1 ]
    [  0.1, -0.1,  0.1 ]
    [ -0.1, -0.1,  0.1 ]
    [ -0.1,  0.1,  0.1 ]
  }
  ELEMENT_CONNECTIONS
  {
    [ 0, 1, 2 ]
    [ 4, 7, 5 ]
    [ 0, 4, 1 ]
    [ 1, 5, 2 ]
    [ 2, 6, 7 ]
    [ 4, 0, 7 ]
    [ 3, 0, 2 ]
    [ 4, 5, 1 ]
    [ 0, 3, 7 ]
    [ 7, 6, 5 ]
    [ 3, 2, 7 ]
    [ 5, 6, 2 ]
  }
  DEFINE_SURFACE_REGIONS
  {
    sr
    {
      INCLUDE_ELEMENTS = [4, 10]
    }
  }
}

MODIFY_SURFACE_REGIONS
{
  /*Cube[sr]*/
  Cube[ALL]
  {
    SURFACE_CLASS = sc
  }
}

INSTANTIATE Scene OBJECT
{
  Cube OBJECT Cube {}
  rel_vm RELEASE_SITE
  {
   SHAPE = Scene.Cube
   MOLECULE = vm
   NUMBER_TO_RELEASE = 1000
  }
  rel_sm RELEASE_SITE
  {
   SHAPE = Scene.Cube
   MOLECULE = sm'
   NUMBER_TO_RELEASE = 1000
  }
}

/*VIZ_OUTPUT*/
/*{*/
/*  MODE = CELLBLENDER*/
/*  FILENAME = "./viz_data/Scene"*/
/*  MOLECULES*/
/*  {*/
/*    NAME_LIST {ALL_MOLECULES}*/
/*    ITERATION_NUMBERS {ALL_DATA @ ALL_ITERATIONS}*/
/*  }*/
/*}*/

REACTION_DATA_OUTPUT
{
  STEP=1e-06
  {COUNT[sm,WORLD]}=> "./react_data/sm.World.dat"
  {COUNT[vm,WORLD]}=> "./react_data/vm.World.dat"
}

Changing the ITERATION_NUMBERS in the viz data block can change the simulation results between two otherwise identical simulations (e.g. changing ITERATION_NUMBERS {ALL_DATA @ [[1000 TO 2000 STEP 5]]} to ITERATION_NUMBERS {ALL_DATA @ [[5000 TO 6000 STEP 5]]}).

This issue is being created because of a problem that Bob reported while creating a tutorial for Fick's Law. I've simplified his original MDL considerably and am including it here. The root of the problem is the fact that some faces in his model are overlapping/coplanar, which results in molecules leaking out. If two faces are identical, MCell will report an error as long as the with_checks flag isn't disabled. We've known that coplanar faces can cause problems in the past and even warn against it in the QRG (http://mcell.org/documentation/qrg/mcell3_qrg.html#avoid-coincident-meshes), but we've never taken any steps to resolve it afaik, aside from the special case where they are completely overlapping (i.e. identical).

ITERATIONS = 500
TIME_STEP = 1e-06

DEFINE_MOLECULES {
  vm { DIFFUSION_CONSTANT_3D = 1e-05 }
}

box BOX {
  CORNERS = [0.01,-0.3,-0.3],[0.09,0.3,0.3]
}

plane POLYGON_LIST {
  VERTEX_LIST
  {
    // The directions (e.g. bottom, top) used below were chosen somewhat
    // arbitrarily by looking along the X-axis (from negative to positive) with
    // the Z-axis pointing up in Blender. 
    //
    // This probably won't look right if you don't use a monospaced font
    /*
       2     3
        -----
        |\  |
        | \ |
        |__\|
       1     0
    */
    [0.01,-0.3,-0.3]  // bottom right
    [0.01,0.3,-0.3]   // bottom left
    [0.01,0.3,0.3]    // top left
    [0.01,-0.3,0.3]   // top right
  }
  ELEMENT_CONNECTIONS
  {
    // The faces and vertices directly overlap. Mcell will catch this as long
    // as the "with_checks" flag isn't set to "no".
    /*[1, 2, 3]*/
    /*[3, 0, 1]*/
    // The vertices directly overlap, but not the faces. Mcell will not catch
    // this.
    [0, 1, 2]
    [2, 3, 0]
  }
}

INSTANTIATE world OBJECT
{
  box OBJECT box {}
  box_rel RELEASE_SITE
  {
    SHAPE = world.box
    MOLECULE = vm
    NUMBER_TO_RELEASE = 250
  }
  plane OBJECT plane {}
}

VIZ_OUTPUT
{
  MODE = CELLBLENDER
  FILENAME = "./viz_data/fick"
  MOLECULES
  {
    NAME_LIST {ALL_MOLECULES}
    ITERATION_NUMBERS {ALL_DATA @ ALL_ITERATIONS}
  }
}

Tri-molecular reactions do not work with microscopic reversibility. Currently, MCell does not detect this at startup and will segfault at run-time since volume molecules have improperly set dissociation indices. Thus, we should add a test during startup which checks for tri-molecular reactions in the presence of microscopic reversibility and aborts the simulations if so.

When you create a meta object with a child box object (or polygon object) and attempt to release within that object without first instantiating it, then an error is generated. Here is an example MDL:

ITERATIONS = 1000
TIME_STEP = 1e-6

DEFINE_MOLECULES{
  A {DIFFUSION_CONSTANT_3D = 1e-05}
}

boxy BOX {
  CORNERS = [-0.5, -0.5, -0.5],[0.5, 0.5, 0.5]
}

meta_box OBJECT {
  box1 OBJECT boxy{}
}

INSTANTIATE Scene OBJECT
{
  rel_A11 RELEASE_SITE
  {
    SHAPE = meta_box.box1
    MOLECULE = A
    NUMBER_TO_RELEASE = 5
  }
}

This will generate the following error:

****************
INTERNAL ERROR at ../src/wall_util.c:973 [is_manifold]: Region 'meta_box.box1,ALL'     has NULL wall array!
MCell has detected an internal program error.
Please report this error to the MCell developers at <[email protected]>.
****************

The species struct member D_ref doesn't serve any obvious purpose and can likely be removed. It will also need to be removed from tests in the testsuite.

Setting RADIAL_DIRECTION or RADIAL_SUBDIVISIONS to zero will give a floating point error. MCell should probably handle this more gracefully.

Branch: dynamic_meshes

Support needs to be added for the INCLUDE_FILE command in the dynamic geometry parser. Note: this only refers to the dynamic geometry parser and not the standard MDL parser.

If you try to instantiate an object with the same name as an object which you have instantiated previously, you get the this fairly unhelpful error message:

Failed to parse input file

Previously, MCell would give a much more useful message like this:

Object 'Scene.Cube' is already defined.

Assuming you have an mdl called Scene.main.mdl, the following command will cause a segmentation fault:

"mcell Scene.main.mdl XXX"

XXX can be any text that is not one of the standard mcell flags (e.g. -seed, -quiet) as long as it doesn't start with a hyphen. For instance, the following command will give an appropriate "unrecognized option" error:

"mcell Scene.main.mdl -XXX"

If you change a unimolecular rate for a reaction between checkpoints, the new rate will not be used. This is because the molecule already has a set lifetime computed from the previous checkpoint.

It would be easy enough to recompute lifetimes at the start of the checkpoint. However, if we do this, then that means results from a simulation using checkpointing won't be identical to those run without checkpointing if unimolecular reactions are involved.

For example, assume you have two identical simulations (aside from the checkpoint iterations value) that have unimolecular reactions. The one is checkpointed after 100 iterations. After this, the checkpoint file is loaded and the simulation runs for another 100 iterations for a total of 200 iterations. Then imagine you run a separate but essentially identical simulation for 200 iterations without checkpointing. Currently, the results would be identical, but, if we change it so that the lifetimes are always recomputed when checkpointing, then they will no longer be identical.

Another option would be to provide some input flag or keyword that forces MCell to recompute lifetimes. This would also be relatively easy to do, but it puts the burden on the user to know when they should or should not use this flag.

Lastly, we could try to automate this, so that lifetimes are only recomputed if unimolecular reactions have changed between checkpoints. This would require us to somehow store this information in the checkpoint file.

We already have them listed for Ubuntu. We should do the same for OSX.

Hi,

Could you please point me to the lines in the code where the proability of reactions are calculated? I have the probability values and need to compute the reaction rates, and was hoping to do a reverse estimation.

I tried the equations in your papers but may be I am missing something - cannot quite get it right. It would be helpful for me to look at the code.

Thanks,

Surya

If you have a molecule with a diffusion constant of zero which is applied to a concentration clamp, MCell will produce the following (unhelpful) error message:

Error: Failed to parse input file

Here's an MDL that produces this error:

ITERATIONS = 1
TIME_STEP = 1e-6

DEFINE_MOLECULES { vol1 { DIFFUSION_CONSTANT_3D = 0 } }

DEFINE_SURFACE_CLASSES { Surface_Class { CLAMP_CONCENTRATION vol1; = 1e-5 } }

Plane POLYGON_LIST {
  VERTEX_LIST {
    [ -0.899999976158142, -0.899999976158142, 0 ]
    [ 0.899999976158142, -0.899999976158142, 0 ]
    [ -0.899999976158142, 0.899999976158142, 0 ]
    [ 0.899999976158142, 0.899999976158142, 0 ]
  }
  ELEMENT_CONNECTIONS {
    [ 1, 2, 0 ]
    [ 1, 3, 2 ]
  }
}

MODIFY_SURFACE_REGIONS { Plane[ALL] { SURFACE_CLASS = Surface_Class } }

INSTANTIATE Scene OBJECT
{
  Plane OBJECT Plane {}
}

There should be a different option for visualizing molecules when using the non-traditional (mirrored geometry) form of PBCs. This could potentially work in one of two ways. Option one: we could have an MCell VIZ_OUTPUT flag that basically expanded the virtual locations of molecule to their "true" locations. Option two: we could add the virtual location to the viz data itself. This would also require a change to CellBlender, such that it knew how to expand the virtual location on the fly.

I set up a basic experiment in 2D to test Mcell. I defined a particle that is going to diffuse in an square. When I tried to fix the positions of the molecules in this square the mcell software give me this error:

Warning: Molecule release is unable to find surface upon which to place molecule t.
  This could be caused by too small of a SITE_DIAMETER on the release site 'World.t_rel'.
Warning: Molecule release is unable to find surface upon which to place molecule t.
  This could be caused by too small of a SITE_DIAMETER on the release site 'World.t_rel'.
Warning: Failed to release 2 molecules from list "World.t_rel" at iteration 0.
Warning: during the simulation some reaction probabilities were greater than 1. You may want to rerun the simulation with the WARNINGS block enabled to get more detail.

The mdl file of the geometry is:

Square POLYGON_LIST
{
  VERTEX_LIST /* in microns */
  {
    [ 0.00000000000000, 0.00000000000000, 00000000000000 ]
    [ 0.00000000000000, 1.00000000000000, 00000000000000 ]
    [ 1.00000000000000, 1.00000000000000, 00000000000000 ]
    [ 1.00000000000000, 0.00000000000000, 00000000000000 ]
  }
  ELEMENT_CONNECTIONS /* Define triangles */
  {
    [ 0, 1, 2 ]
    [ 0, 2, 3 ]
  }
  DEFINE_SURFACE_REGIONS
  {
    top
    {
      ELEMENT_LIST = [0, 1]
    }
  }
}

and the mdl file of the experiment is:

ITERATIONS = 100
TIME_STEP = 1E-5

/* Define molecules. The units for diffusion are cm^2 s^(-1) */

DEFINE_MOLECULES{
  a {
    DIFFUSION_CONSTANT_2D = 1E-6
    }
  t {
    DIFFUSION_CONSTANT_2D = 0
    }
}

INTERACTION_RADIUS=0.005

/* The rate is defined inside the brackets */
DEFINE_REACTIONS {
  /* annihilation of a */
  a' + t' -> t' [1e8] : annih
}
/* Some files could be useful to be included separately */


INCLUDE_FILE = "./Square.mdl"

INSTANTIATE World OBJECT {
  Square OBJECT Square{}

  a_rel RELEASE_SITE {
  SHAPE = World.Square[top]
  MOLECULE = a'
  NUMBER_TO_RELEASE = 2000
  RELEASE_PROBABILITY = 1
  }
  t_rel RELEASE_SITE {
  SHAPE = LIST
  RELEASE_PROBABILITY = 1
  SITE_DIAMETER = 100 /* for some strange reason this is given a releasing error */
  MOLECULE_POSITIONS
  {
    t' [ 0.20000000000000, 0.20000000000000, 0.00000000000000 ]
    t' [ 0.20000000000000, 0.80000000000000, 0.00000000000000 ]
    t' [ 0.80000000000000, 0.20000000000000, 0.00000000000000 ]
    t' [ 0.80000000000000, 0.80000000000000, 0.00000000000000 ]
  }
  }
}

Thanks in advance!

It is not possible to change a unimolecular rate constant via checkpointing.

Currently, periodic boundary conditions only apply to volume molecules, but they should work for surface molecules as well. This is a much easier problem for volume molecules, since we always know when a volume molecule crosses/intersects a wall as it is ray tracing (like the wall of the periodic box), but the same is not true for surface molecules.

This bug can be triggered using the following MDL:

WARNINGS { ALL_WARNINGS = IGNORED }
ITERATIONS = 10
TIME_STEP = 1e-6

DEFINE_SURFACE_CLASS surf {}
DEFINE_MOLECULES { V { DIFFUSION_CONSTANT_3D = 2e-6 } }
DEFINE_REACTIONS { V;@surf;->NULL [1e-4] }

INSTANTIATE world OBJECT {
    box BOX {
        CORNERS = [-0.25, -0.25, -0.25], [0.25, 0.25, 0.25]
        DEFINE_SURFACE_REGIONS {
            r {
                INCLUDE_ELEMENTS = [ALL_ELEMENTS]
                SURFACE_CLASS = surf
            }
        }
    }
    release_site RELEASE_SITE { SHAPE = world.box[r] MOLECULE = V NUMBER_TO_RELEASE = 100 }
}

Even when using "WARNINGS {ALL_WARNINGS = IGNORED}", the following is still printed:

"Warning: Probability less than EPS_C for reaction between..."

Furthermore, this message is not very meaningful for the user, and it’s questionable whether it shouldn’t even be a warning message at all.

Branch: dynamic_meshes

If a molecule is between a set of intersecting reflective meshes, then it's possible for the molecule to leak out of that space (when the meshes move).

Currently, to count surface hits, one needs to load the whole file with surface hits as in example mcell_tests, branch pymcell_membranes:
examples_pymcell/0100_2_molecule_types_diffuse_in_box_w_plane/pymcell/0100_2_molecule_types_diffuse_in_box_w_plane.py

We will need a better way how to provide the hit trigger information to the python layer.

If the C99 flag is set, then non-empty surface classes will be reported with the reaction probabilities and warnings like this:

Reaction probabilities generated for the following reactions:
        Probability 1.4716e+131 set for A{0} @ absorb{1} -> NULL 

...

Warning: During the simulation some reaction probabilities were greater than 1.You may want to rerun the simulation with the WARNINGS block enabled to get more detail.

This behaviour has only been observed with 32-bit builds. 64-bit builds behave properly.

The following line in Makefile.am enables the C99 flag:

AM_CFLAGS+=-Wall -std=c99 -D_GNU_SOURCE=1

Checkpointing using wall time or SIGUSR1/2 is not documented in the Quick Reference Guide.

Change DYNAMIC_GEOMETRY_RANDOM = FALSE/TRUE to DYNAMIC_GEOMETRY_MOLECULE_PLACEMENT = NEAREST_POINT/NEAREST_TRIANGLE. Also, set the default to NEAREST_POINT.

If you try to build the distribution created by sdist (python setup sdist; cd dist; python setup.py build), it will fail when using the nfsim_dynamic_meshes_pymcell branch because the requirements.py file is trying to use submodules(nfsim, etc), but there are no submodules in the context of the sdist.

Hello,

I am in the process of converting MCell3.mdl files to be compatible with MCell4/CellBlender. I received the following warning and error while trying to perform the conversion. I was looking for resources on specific fixes I need to perform on the mdl code to be compatible with MCell4.
ISSUES:
ERROR: TODO_CONVERSION: reactions with 3 reactants are not supported

Question: Not sure which reactants are not being supported? Do I need to look into reaction probabilities or does this have to do with orientation?

WARNING: Partitioning was specified, but it is smaller than the automatically determined bounding box. You may need to increase the partition size if get an error later that a vertex does not fit any partition.

Question: Again, not sure if this would need to be fixed in the MDL/Data Model prior to running the conversion?

I am hoping this is the best space to address these questions?

Thanks,
am

We should look into deprecating or removing all references to DReAMM visualization commands (e.g. DREAMM_V3 MODE) from the Quick Reference Guide.

Currently, the parser allows that CHECKPOINT_REALTIME is set without any definition of CHECKPOINT_INFILE or CHECKPOINT_OUTFILE. This leads to a runtime segmentation fault.

Solution: Make sure that the init code checks that CHECKPOINT_INFILE and friends are defined when a CHECKPOINT_REALTIME is set and abort otherwise.