mcellteam / cellblender Goto Github PK

CellBlender uses a variety of paths for things like visualization data and 
reaction output (and possibly more).

The purpose of this task will be to make all such paths relative to the 
location of the .blend file. So if a .blend file is moved from one place to 
another, then all of the paths used by CellBlender should move with the .blend 
file to the new location.

Note that there may be some problems with this if the .blend file stores any 
external "state" regarding the status of external files. If the .blend file is 
moved, then the stored state may (likely) be inconsistent with the external 
files at that new location.

Note that this task may also have implications in the flexibility of sharing 
files in common locations.

For all of these reasons, the initial changes will try to leave the old code 
inside comments in case this new behavior is to be removed or made as an option.

In the current implementation, many properties are stored by name instead of 
reference/pointer, which can lead to problems when updating a CellBlender 
model. For instance, a molecule has a name which is simply a string property. 
That same molecule name might appear in other places like reactions and release 
sites. If the original molecule name is updated, that change won't be known or 
propagated to the reactions and release sites. This illustrates a fundamental 
problem in how properties are stored, and the fix will almost certainly break 
previous CellBlender models.

The README has not been updated in some time and is out-of-date in a number of 
places. This should be fixed for the upcoming 1.0 release. The introduction 
should be updated. The "Installing" and "Activating" sections can pretty much 
stay the same (aside from the filename). The "Using CellBlender" section can 
probably be largely eliminated and instead simply point to the tutorials.

Reproduce the problem with these steps:

  1. Start Blender (with CellBlender addon installed and enabled)
  2. File / Load Factory Settings
  3. File / Load Factory Settings

After the first Load of Factory Settings, the console shows:
===========================================================
    addon_utils.reset_all unloading cellblender
CellBlender unregistered
Traceback (most recent call last):
  File "/home/bobkuczewski/.config/blender/2.66/scripts/addons/cellblender/cellblender_operators.py", line 1311, in clear_run_list
    processes_list = context.scene.mcell.run_simulation.processes_list
AttributeError: 'tuple' object has no attribute 'processes_list'
Traceback (most recent call last):
  File "/home/bobkuczewski/.config/blender/2.66/scripts/addons/cellblender/cellblender_operators.py", line 2246, in model_objects_update
    if ((len(model_obj_names) == 0) & (len(mobjs.object_list) > 0)):
AttributeError: 'tuple' object has no attribute 'object_list'
===========================================================

After the second unload, the console shows:
===========================================================
Writing: /tmp/blender.crash.txt
===========================================================

Here are the contents of /tmp/blender.crash.txt:
===========================================================
# Blender 2.66 (sub 1), Revision: 55057

# backtrace
blender2661() [0xea6c1c]
blender2661() [0xea6e5a]
/lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [0x7f654b2f04f0]
blender2661() [0x16cb496]
blender2661(pyrna_struct_CreatePyObject+0x25) [0x16cabb5]
blender2661(pyrna_prop_to_py+0xde) [0x16ced0e]
blender2661() [0x16cf090]
blender2661(PyEval_EvalFrameEx+0x2a00) [0x2973eb0]
blender2661(PyEval_EvalCodeEx+0x81e) [0x29713fe]
blender2661() [0x28f13cf]
blender2661(PyObject_Call+0x5a) [0x28cb96a]
blender2661(bpy_app_generic_callback+0x8c) [0x16c600c]
blender2661(BLI_callback_exec+0x2d) [0x172d5ed]
blender2661(wm_homefile_read+0x12f) [0xeaea8f]
blender2661(wm_homefile_read_exec+0x32) [0xeaec72]
blender2661() [0xec065b]
blender2661() [0xec0b8c]
blender2661() [0x114fd86]
blender2661() [0x115cf9b]
blender2661() [0xec1aec]
blender2661() [0xec2106]
blender2661(wm_event_do_handlers+0x198) [0xec2408]
blender2661(WM_main+0x18) [0xeae008]
blender2661(main+0x2b0) [0xea9114]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f654b2dcead]
blender2661() [0xde5305]
===========================================================

When stepping through visualization files, I've noticed the following odd 
behavior:

1: Show intro.cellbin.0000.dat, all molecules appear correct
2: Show intro.cellbin.0001.dat, all move, but some (all?) newly created 
molecules don't appear
3: Show intro.cellbin.0002.dat, all molecules appear correct again (all show up 
and move)
4: Show intro.cellbin.0001.dat (go back), all are now correct and the "missing" 
molecules appear
5: Show intro.cellbin.0000.dat (go back again), all appear as in Step 1.
6: Show intro.cellbin.0001.dat (go forward again), newly created molecules 
still don't appear.

To summarize, stepping forward seems to skip some of the molecules that are 
newly created after initialization (possibly only on the first step), but 
stepping backward appears to display them all properly.

I've given this a low priority, but I did want to document it.

The orientation is not being applied for molecules in Blender 2.66. This 
results in all molecules having the same vertex normal. In more practical 
terms, this means that all molecules will point up along the global z-axis. 
This will be most noticeable when using a glyph/shape with an obvious 
directionality to it like the Cone.

Apparently property arrays are limited to 65535 elements.

This mean that you can't have a region with more than this many
faces.  One possible fix is to store large regions as multiple arrays.

If you have two meta objects each with identical named polygon objects within 
them, then CellBlender will only import one of those of objects. For example, 
assume you have the following MDL:

meta_obj1 OBJECT {
  poly_obj POLYGON_LIST {
    ...
  }
}

meta_obj2 OBJECT {
  poly_obj POLYGON_LIST {
    ...
  }
}

Only one of the "poly_obj" objects will actually be imported. However, if the 
polygon objects have unique names, then this will work correctly, as in this 
example:

meta_obj1 OBJECT {
  poly_obj1 POLYGON_LIST {
    ...
  }
}

meta_obj2 OBJECT {
  poly_obj2 POLYGON_LIST {
    ...
  }
}

In the first example, we need to take care of naming conflicts to solve the 
problem. One possibility would be to import them with  fully qualified names 
(i.e "meta_obj1.poly_obj" and "meta_obj2.poly_obj"). 

CellBlender does not support the following features for COUNT statements:

-Surface molecules with a specified surface orientation
-ALL_ENCLOSED
-ESTIMATE_CONC
-hits and crossings (FRONT_HITS, BACK_HITS, ALL_HITS, FRONT_CROSSINGS, 
BACK_CROSSINGS, and ALL_CROSSINGS)

This will likely be an ongoing task to keep the tutorials up to date.

This is just a test to see if the "Activity Notifications" feature under 
Administer>Issue Tracking will automatically send out an email when a new task 
is created. 

It's possible for users to export meshes that are not triangulated. To solve 
this, we could either automatically triangulate meshes or at least warn them 
that their meshes aren't triangulated at an appropriate time. We would likely 
want to do this when meshes are being added to the Model Objects list and/or 
the first time a surface region is being defined for an object. It might be 
considered bad practice to modify a user's mesh without their knowledge, 
although this is likely what everyone using CellBlender would want. Maybe we 
could make it an option under the proposed CellBlender Preferences panel. Any 
thoughts on the matter?

Describe the new task that you think might need to be accomplished within
the CellBlender project.

With regards to initialization commands, CellBlender only allows users to 
change the number of iterations and the time step, but there are many other 
optional commands (including notifications and warnings) that still need to be 
added.

MCell documentation on initialization commands:
http://www.mcell.org/documentation/mcell3_qrg.xhtml#magicparlabel-131

A context error is sometimes generated when trying to run a simulation after 
having previously deleted an object (mesh, camera, lamp, etc). Selecting 
another object before running the simulation prevents this error for some 
reason. This is the traceback:

Traceback (most recent call last):
  File "/home/jacob/.config/blender/2.70/scripts/addons/cellblender/cellblender_operators.py", line 1200, in execute
    bpy.ops.mcell.export_project()
  File "/home/jacob/bin/blender/blender-2.70-linux-glibc211-x86_64/2.70/scripts/modules/bpy/ops.py", line 188, in __call__
    ret = op_call(self.idname_py(), None, kw)
RuntimeError: Error: Traceback (most recent call last):
  File "/home/jacob/.config/blender/2.70/scripts/addons/cellblender/cellblender_operators.py", line 1463, in execute
    bpy.ops.export_mdl_mesh.mdl('EXEC_DEFAULT', filepath=filepath)
  File "/home/jacob/bin/blender/blender-2.70-linux-glibc211-x86_64/2.70/scripts/modules/bpy/ops.py", line 186, in __call__
    ret = op_call(self.idname_py(), C_dict, kw, C_exec, C_undo)
RuntimeError: Operator bpy.ops.export_mdl_mesh.mdl.poll() failed, context is 
incorrect

Fix regions so that each polygon knows its region memberships. This is 
necessary so that deletion or insertion of new polygons in a mesh, which causes 
re-indexing of the mesh polygons, does not mangle the region memberships.  
We'll need to store an array of region id's with each polygon, indicating it's 
membership in those regions.  The region id's will need to be unique id's which 
map to the appropriate region so that changes in region names will not mangle 
the region memberships. So, the unique id's will need to be a new class 
variable added to the named regions and the polygons which are a member of a 
given region will be assigned the id of that region.  A question is how to 
guarantee that the id's are truly unique.  Do they need to be unique within an 
object, within a CellBlender project, or in the universe of projects?  If they 
are not unique in the universe of projects then appending objects between 
CellBlender projects will require special handling (i.e re-assignment of unique 
id's to named regions and their associated polygons). We'll need to  discuss 
this.

The official testbuild for Blender 2.66 does not work properly with the current 
version of CellBlender. The changes made to the template list in 2.66 are at 
least partially (if not entirely) responsible. Documentation can be found here:

http://www.blender.org/documentation/blender_python_api_2_65_8/bpy.types.UIList.
html

Hopefully, this can be done in one place by tacking the new directory names to 
the file names before they're passed to the actual plotting functions.

Give users the ability to create partitions within CellBlender for an MCell 
simulation.

MCell documentation on partitions:
http://www.mcell.org/documentation/mcell3_qrg.xhtml#magicparlabel-3760

Example of partitions used in an MDL:

PARTITION_X = [ [-0.1 TO 0.1 STEP 0.01] ]
PARTITION_Y = [ [-0.1 TO 0.1 STEP 0.01] ]
PARTITION_Z = [ [-0.1 TO 0.1 STEP 0.01] ]

A Lattice object might work well for a visual representation of partition 
boundaries and spacing.

Although we previously attempted to change all uses of absolute directories to 
relative directories in CellBlender, we must have missed the viz directory. One 
should be able to move a blend file and the associated project directory around 
without needing to regenerate the viz data (i.e. rerun the simulation).

Creating a test suite for a GUI can be difficult. However, given the nature of 
Blender's operators (i.e. every button press can be scripted), we can automate 
at least some of the testing for CellBlender. Specifically, we can have a 
script that essentially creates a CellBlender project from scratch, exports the 
MDLs, runs the simulation, and imports the viz data. Assuming there are some 
features that we cannot create in an automated fashion, then we could 
additionally include blend files that make use of said features.

Add a mechanism which allows CellBlender users to plot various kinds of data 
from within CellBlender.

Initially, this may be simple canned plots of reaction data, but should 
ultimately be expandable to more general plotting.

This task came from our Google hang out discussion on March 27th, 2013.

CellBlender does not currently support MCell's list based release sites. This 
can be quite useful if there are many molecules of one type that you want to 
release at specific XYZ locations.

Here is an example of what this looks like in MDL:


Release_Site RELEASE_SITE
{
  SHAPE = LIST
  MOLECULE_POSITIONS
  {
    Molecule
    [.1, .1, .1]
    Molecule
    [.2, .1, .1]
    ...
  }  
}

On Wednesday's meeting, we discussed how to handle cases where the user begins 
running a new simulation and there is already viz and/or rxn data present from 
previous simulations. We agreed to present the user with two options: remove 
the existing data or append to it. Removing is usually the logical choice if 
you have changed any simulation settings. Appending makes sense if you simply 
need to run some additional seed values (e.g. You want to run seed values 
11-100 after having previously run 1-10).

Come up with a way to tag CellBlender versions for the purpose of identifying 
(and possibly recovering from) incompatibilities between different versions of 
the CellBlender addon and the .blend files produced by different versions of 
the CellBlender addon.

Initial direction is to make an effort to incorporate the GIT hash tags in some 
way so that they can be used to identify the addon version and potentially 
stamp that into the .blend file so that it may be checked at run time.

The previous CellBlender .blend files (may) have no known identification 
information in them, so one thought is that their "version string" might be 
defaulted to "Unknown".

Release patterns (http://www.mcell.org/tutorials/rel_pattern.html) are not 
currently supported in CellBlender.

Currently, we can only define static rate constants for reactions in 
CellBlender, even though MCell supports time-dependent rate constants. In the 
MDL, this is done by referring to a filename, which has two columns: the first 
being the time and the second being the rate constant. Perhaps the simplest way 
to support this in CellBlender would be to let the user click a file navigator 
button to select such a file. The file would then be created in the project 
directory upon export. This could either be accomplished by simply copying the 
file (problematic if the original file moves) or the contents could be stored 
within the blend file and written out upon export.

The API version number should be stored in the blend file by the release of 
CellBlender 1.0. This will help us more gracefully handle version changes and 
compatibility issues for users.

Under the "Visualization Output Settings" panel, there is a button called 
"Toggle All" which refers to the list of molecules to be visualized. We should 
replace that button with a simple check box that, if selected, will always 
visualize all the available species. This prevents the problem of having to 
continually go back and select new molecules to be visualized every time a new 
one is defined.

Design overall architecture and interoperability of CellBlender and libMCell.

CellBlender will not import over existing objects with the same name. It will 
leave the existing object there without any warning/error. If you try to delete 
the existing object first, it will bring that object back when you try to 
import the new object.

When a user creates an invalid entry, a status message indicating the nature of 
the error will be printed in the panel. Once that user starts to change another 
item in the list, the status message will be replaced by a new status message 
or nothing at all. The user no longer has a record of what was wrong with the 
original item. 

If we associate the status with the items themselves, however, we could keep 
track of what is wrong with a given item. For instance, we could add an error 
icon and message to any invalid entries thus creating a quick visual reference 
of what needs to be fixed. Furthermore, on export, we could filter out any 
entries that have errors associated with them, thus lessening the chances of 
invalid models being created.

One problem with this approach is that since we still don't have a perfect 
solution for the "store by reference" problem, then some things will appear to 
be valid when they are in fact invalid and vice versa.

I'm attaching an image of how this interface might look in the Define Reactions 
panel.

I've gotten some interesting results if I run a simulation for 2000 iterations, 
change the model, and then run it again for only 1000 iterations. The higher 
numbered viz files (1001 to 2000) are still around and get read by the 
simulation when it runs.

This is a pretty low priority problem, but I just wanted to get it on the list 
somewhere.

This task is building on the work done by Dipak which imports BNGL parameters.

The goal is to allow setting and evaluation of parameters.

Parameters should retain their identity and participation in expressions when 
their name is changed.

Changes to any parameter should cause updates to all other parameters which use 
it in their own expressions.

Hello everyone, 
I'm faizal fajrie, nice to know you all, 
I'm interest in MCell and my final research in graduate is use program MCell, 
where I start this?
and I'm use ubuntu 12.04 LTS,
thanks for your attention.
hope I can learn everything about MCell and Cellblender from you all.

Best Regards.
Faizal Fajrie

Currently can only assign faces to region in "face select mode".  Fix
this so that we can also use vertex, and edge select modes. Note, this
will still mean that only full faces are assigned (i.e. incomplete sets
of vertices or edges that don't map to a full face will be ignored). 

When you mouseover a button, drop-down menu, float property, check box, or 
other UI element, a description of what that element does is presented to the 
user (assuming the description exists). Many of the UI elements already have 
descriptions, but some are still missing. This is a simple addition that can be 
very useful to the user. Since there is very little chance of this breaking 
anything, I think it should be added to release_candidate_1.0.

The current version doesn't seem to save the mcell path between runs. I think 
it should be storing this in the .blend file, and I will look into fixing this.

Currently, we add a new molecule, reaction, release site, or surface class to 
the relevant template_list with some default (and possibly invalid) values. In 
effect, this means the user can create broken models. Instead, it might be 
better to first have the user fill out some blank template fields, and, only 
after having validated it, we allow it into the list.

The Blender API is fairly rich and fairly complex. This is a personal learning 
task to become familiar enough with the Blender API to assist with the 
CellBlender implementation.

Add button to delete all surface regions defined on an object.

Currently, in CellBlender molecules and surface classes can have the same name. 
However, in MCell this is illegal, which makes sense since surface classes can 
appear in reactions. As such, a warning/error should also be generated in 
CellBlender when a user attempts to define a molecule with the same name as a 
surface class and vice versa. 

The goal of this issue is similar to Issue 12 in that both of them are 
concerned with making CellBlender stand out more. However, to the best of my 
knowledge, we cannot create our own Editor in Blender at this time using the 
Blender Python API. As a compromise, Markus suggested simply adding a prefix to 
each of the panels with the word "CellBlender". For instance, the "Model 
Objects" panel would become "CellBlender - Model Objects". Obviously, this is 
not nearly as nice as having our own Editor space, but it's a simple change to 
make, and it really helps everything stand out imo. Does anyone have a problem 
with this change? 

MDL transforms (SCALE, ROTATE, TRANSLATE) should be supported by the Python 
mesh importer.

Post suggestions for Python APIs that express various aspects of MDL.

This task resulted from today's meeting (March 20th, 2013). This task is 
intended to capture as many creative ideas as possible, so please feel free to 
toss in any ideas you have.

I believe that reactions might be the most difficult to represent pythonically 
(other than as strings) because they use commas and apostrophe's which have 
special meanings in Python and are not overloadable. So with that thought in 
mind, I've included the reaction examples from the quick reference guide below. 
Any proposed pythonic API would have to be able to express all of these 
examples.

Examples from Quick Reference Guide (units were dropped for ASCII simplicity):

    Example = Explanation

    A -> B [100] = Molecule A changes into molecule B at a rate of 100
    A -> A + B [100] = Molecule A emits molecules of B at a rate of 100
    A -> NULL [100] = Molecule A is destroyed at a rate of 100
    A + B -> A [1e6] = Molecule A destroys molecule B at a rate of 1e6
    A + B -> A + C [1e6] = Molecule A catalytically converts B to C at a rate of 1e6
    A+B -> A+B+C [1e6] = Collision of A and B catalytically generates C at a rate of 1e6

    B' -> B, [10] = Molecule B flips (changes its orientation) at a rate of 10
    B' -> B' + A' + C, [10] = Molecule B emits molecules of A on the side it's pointing to and emits C on the other side, at a rate of 10
    B, -> B, + A, + C' [10] = This specifies exactly the same reaction as above. B and A end up with the same orientation, while C has opposite orientation.

    A' + B' -> C' [1e5] = Molecule A binds to B if it is on the side that B is pointing to, producing a C facing the same way as B, at a rate of 1e5
    A, + B, -> C, [1e5] = The same reaction again-everything occurs on the same side, but we wrote it on the bottom this time.
    A' + B, -> C' [1e5] = Molecule A binds when it hits the opposite side of B, producing a C facing the opposite way as B (i.e. towards the side A came from), at a rate of 1e5
    A, + B' -> C, [1e5] = Same as above

    A'' + B, -> C' [1e5] = Molecule A binds to either side of B (since they are in different orientation classes); this produces a C facing the opposite way as B, at a rate of 1e5
    A,, + B, -> C' [1e5] = This is the same reaction-since A is the only molecule in the second orientation class, it doesn't matter which way we specify things.
    A,, + B' -> C, [1e5] = Same again- B and C still have opposite orientations.
    A, + B' -> C,, [1e5] = Molecule A hits the opposite side of B and produces C that is equally likely to point either way, at a rate of 1e5
    A, + B' -> C'' [1e5] = Same as above, since C is still not in the same orientation class as the others.
    A'+B'' -> A,+B''' [1e5] = Molecule A hits molecule B on either side; A keeps traveling (goes to the other side) and B tumbles to a random orientation, at a rate of 1e5
    A'+B'' -> C'''+D'''' [1e5] = A and B react in any orientation and produce C and D in random orientations. All orientation classes are different, so there are no geometrical constraints here.

    A' + B' @ surf' -> C, [1e5] = The reaction affects surface molecules B located on surface regions identified by surface class surf which have their top domain at the front of the surface. B reacts with A approaching from the front at a rate of 1e5 to yield surface molecule C whose orientation is flipped with respect to B, i.e., C has its top domain aligned to the back of the surface regions.
    A' + B, @ surf' -> C, [1e5] = Same as above, but B now has its top domain at the back of the surface and reaction product C assumes the same orientation.

    A,, + B, @ surf' -> C' [1e5] = Since A is in an orientation class different from both B and surf, A can react from both sides. B has its top domain at the back of the surface and the reaction product has its orientation flipped, i.e., its top domain is at the front of the surface.
    A' + B' @ surf' -> C,, [1e5] = Same as the the first reaction, but since product C is in a orientation class different from either A, B, and surf, its orientation is random with respect to the surface regions, i.e., its top domain can be either on the front or back.

    A + B + C -> D [1e12] = Volume molecules A, B and C react to yield product D, at a rate 1e12
    A + B + C -> D + E + F [1e11] = Volume molecule A, B and C react to yield the three volume products D, E and F at a rate of 1e11
    A' + B' + S, -> D' [1e12] = Volume molecules A and B both react with the bottom of surface molecule S to yield volume product D which is released toward the same side from which A and B came from at a rate of 1e12
    A, + B, + S' -> D, [1e12] = This reaction is identical to the previous one.
    A, + B, + S' -> A' + B' + S' [1e9] = This reaction describes the action of a surface bound symporter molecule S. Molecules A and B bind to the bottom of S which then re-releases A and B at its top domain. This reaction happens with a rate of 1e9
    A, + B' + S' -> A' + B, + S' [1e9] = This is similar to the previous reaction but S now acts as an antiporter for A and B.
    A, + S' + R'' -> T'' [1e11] = In this reaction, volume molecule A facilitates the dimerization of surface molecules S and R. A reacts with the bottom of S and R in arbitrary orientation to produce a dimer T that is oriented like R. The reaction happens with a rate of 1e11
    R, + S, + T'' -> T''+ U,,, [1e11] = Identically oriented surface molecules R and S dimerize in the presence of surface molecule T which is oriented opposite to both R and S. The reaction regenerates T in its original orientation and creates the dimer U which can have an arbitrary orientation. This reaction occurs at a rate of 1e11

We allow the counting of named reactions (e.g. "my_rxn" in "a->NULL [1e3] 
my_rxn"), but reaction counts cannot currently be plotted.

Having CellBlender live under the "Scene" tab of the Properties Space
is workable but is not our ideal solution.  It would be better to add
a new custom "CellBlender" tab to the Properties Space or perhaps a 
whole new "CellBlender" Space Type.  But it's not clear if either of 
these solutions is possible.  Let's explore the possibilities...

Look into C++ coding standards for libMCell.

The CHANGELOG needs updated to mention any significant features and bug fixes 
that have been added since the last release (1.0 RC).

Make minimal changes to allow CellBlender to be functional without needing to 
hand-edit MDL files or run mcell from the command line.

This task is intended to offer just enough support for simple projects, but 
hand-editing of MDL may still be required to take advantage of more advanced 
MCell features.