Future Plans

TO DO

  • Volumetric rendering
  • Tensor Rendering (Ben Morgan implemented glyph rendering, this needs to be merged with Jeff’s surface render form

    • Make use of self.RenderTensor(mytensordata) (see meshCommands.py)

  • New Equations Editors:
    • Circulatory Model
    • Coordinates
    • Basis Function
      • Move PXI call to python and create new PG_PXI data structure that gets passed all over the place
      • Calculate the new grid basis function array in Calculate Mesh where the default grid locations will also be set.

      • See this page for more details

    • Algebraic variables needs to be better tested with sympy based equation editors
  • Higher level scripting of boundary conditions
  • Better tools for mesh generation with imaging module (cylinders isn’t quite good enough)
  • sqlite based default database to store local Continuity models
  • Symbolic variables for “#;”
  • Time Units (1000* thing)
  • Fix dynamic make system
  • Remake binaries; update dynamic build system
  • Annoying “not all binaries” message
  • Use new sympy code gen w/ material coordinates (it uses an older system)
  • Unify ODE calling convention in Electrophysiology.py

  • Spatially coupled variable -> dependent state variable

  • Vm shouldn’t be removable and should always be spatially coupled
  • Can radau be used with a C based cell model?
  • cvode solver instead of my solver? (SUNDIALS or CVODE?)
  • Custom color maps
  • Automatic singularity detection
  • Electromechanics needs fixing
  • sympy based hydrostatic pressure example?
  • New List Element Form (based on new list Stress/Strain form)
  • Altenative ODE solver
  • Nodes form:
    • Incorporate Edit Basis Functions directly into Edit Nodes form

    • Have Continuity automatically add a standard list of basis functions at startup (could be in a DefaultBasisFunctions.Cont6 file loaded at startup)

    • Add a “Choose…” option to the end of the pop-up menu in Edits Nodes that opens the current Edit Basis form with the preselected Basis function list already added

    • Add a “Save as Default” button in the current Edit Basis form that saves the default Basis functions to the DefaultBasisFunctions.cont6 file thats get read at startup. Expanding on this: We might want to have a startup folder that contains cont6 files that have defaults for all of the modules that we use, and they are read in as modules are loaded, with mesh being first.

    • Edit Basis Functions can stay (until it is replaced by a Model Editor)
    • Eventually remove Gauss Points from Edit Basis form and Add to Edit Nodes form. Just one set of Gauss Points per problem than per basis function. So 3*3*3 etc will be removed from Basis Function list
    • Implement description and units metadata for geometric and field variables
    • Add the ability to name a field or coordinate variable

    • Remove fiber angle variables they are no longer necessary, and could just be replaced with 3 normal field variables

    • Make a separate tab for each variable rather than three per page. By default show only three coordinate tabs with a + or “More” tab at the end that creates a new (named) field variable. The field variable name could be displayed in the tab, though it would avoid making the winow too wide and having to scroll if the fourth tab was a (editable?) pop-up menu
  • GUI Streamlining:
    • Replace OK buttons in appropriate forms with “Submit” and “Submit and Update” (default) buttons. Submit and Update will Submit, Send, Calculate Mesh, Re-render and hide old renderings all at once
    • New take on the above method is to have an new Update button in the GUI toolbar which would do the updating, and the form would ideally have a submit button so it can submit the data without closing, so updates can happen more dynamically while the form is open. This update button would also be accessible from the main menu bar, and would ideally have a list of the things that can be updated, and the user can choose the specific thing to update and/or edit the list of items in the update list.

    • This might be facilitated by adding a “Hide previous” checkbox in the rendering dialogs that would by default hide the last object of the same kind made by that particular command. E.g. Render Elements makes more than one kind of object (Lines, Surfaces, textures) that OpenMesh keeps track of. The next time you render lines, by default it would hide the previous rendering of lines. This doesn’t need to be perfect but the default could potentially be fairly intelligent, e.g. so that if you rendered surfaces on a different Xi plane or you rendered deformed lines after undeformed lines it would uncheck the “Hide previous” checkbox. More importantly, this would be implemented in such a way that it could work from a script so that when Submit and Update re-renders, the last rendering would be automatically hidden appropriately. This would reduce the amount of state info that has to be kept track of essentially just to what had been rendered already (which OpenMesh already knows)

    • Add more toolbar buttons for all Edit, Render and Solve commands.
      • Make buttons smaller and allow for two or more rows of buttons; note the the toolbar strip is already scrollable. Smaller buttons would look most professional
    • Clean up menus to get rid of redundant or unconventional commands. E.g. replace “Load” with “Open…”
    • Consider removing menubars from Imaging and Model Editor windows and replacing with toolbars
    • Make “Forms” smaller e.g. “Edit Elements …” (Elements Form) is far bigger than it needs to be.
  • Changing Model Save Location and Compilation verification
    • Save all model metadata, including equations in Cont6 file, also include hexstring if the model has been compiled.
    • Now when we compile, we will generate a hexstring from the source code that is being compiled. Source code being the auto-generated C code that arises from the sympy code. This allows for other changes in the model (e.g., descriptions, units, etc) to happen without requiring to compile again. The code generation should happen on the client, with the compilation still happening on the server.
    • The hexstring will be generated on the server, and the resultant shareable object that gets generated from the C code will get that hexstring as it’s name, instead of being the model’s as it’s done now.
    • If a client’s hexstring == sever’s hexstring, then no compilation necessary.
    • If a client has a hexstring, that means it’s been compiled before, but until there’s a server-side comparison with the client’s hexstring, we don’t know if there is a matching binary, so it’s basically uncompiled until this check is performed.
    • Upon opening the Model Editor, if the client has a hexstring already associated with the loaded model, we’ll do a server-side check to see if there’s a matching hexstring, and if so, mark the model as compiled on the compile tab.
  • Model Editor changes
    • Now, we can even remove the parameter tab and have the parameters defined within the Edit Equations tab (although, there really won’t be any more tabs there). The parameters will be just like other variables in the display, with a type ‘parameter’, but when clicking on the parameter, we’ll get the existing parameter tab info displayed where the equations are entered for the other variables
    • Can remove, Select Model, Edit Properties, Compile, Submit and View Equations tabs, leaving just Edit Equations and Set Parameters (others will need Initial Conditions tab).
    • The remaining tabs will retain the same format (left/right panes), and the bottom left pane will now have additional buttons for: Open, Submit, Compile, View Code, View, Equations, and Save. Or, we could have View Equations button, which would open a new window, and one tab would be the equations and one tab would be the C code.
    • Compile button will be dynamic: Greyed out when things are compiled, not greyed when something changes and needs to be compiled
    • Previous thoughts retained below should we still want to incorporate some of these ideas
    • No longer have first 2 tabs (Select model and Edit Properties) and move the information from Edit Properties to Edit Equations, although omitting the Author field as that’s no longer necessary. The database will hold that information. There may be left over code in there that tries to figure out who owns the model. that can all be removed.
    • Also possibly remove the Submit tab, and include a Submit button on all the remaining tabs, to allow users the ability to submit at anytime.
    • On Edit Equations, the root folder currently called ‘Variables’ will have the model name with the accompanying description being the model description.
    • On Compile Tab, next to the Compile button, instead of the model’s name show the server-side hexstring file name. Show something indicating the model needs to be compiled if a) there’s no hexstring on server b) the client’s hexstring doesn’t match the hexstring on server. The hex string can be generated by a particular python function (ask Johan which one Instant uses) that takes a string (the source code plus any other platform independent input to the compiler like optional flags) and returns the unique hex key that will be used for the name of the compiled binary that is saved on the server. This string will be generated at the time the model is “saved” in the compile tab (i.e. at the time of code generation) and its value is saved in the cont6 file. When an existing model is opened in the editor, the editor will first look on the server for a file with a matching name. Because the name itself is based on platform-independent information, then this should allow the user to compile the same model on different platforms and switch between platforms without having to recompile. This approach will also allow users to change the model equations and resave a cont6 without automatically having to regenerate code and recompile if they know that the changes will not affect the code.
    • Until we get the DB more integrated, we’ll use the ‘File’ menu option to view/open models. The File option will, by default, open up in the proper directory on the client for that particular model type (i.e., Biomechanics, EP, etc). Hence, the model editor listing will now be done through an operating system file browser, instead of automatically listing all available models directly in the model editor. The main design change here is that the model definitions are now being stored on the client, not the server as we currently do

    • We want the models stored in a user’s workspace on the client, first thought is in the .continuity/<model_type> since we already create that works space

    • Keep the models stored in a format we already can work with (e.g., .xls or cont6) and just open/save them using the existing tools.
  • Image Editor changes
    • One thought on how to redesign the image editor is to take all the top tabs and have them vertically stacked along the left side of the main frame, and take all the tabs on the bottom portion of the screen and stack them vertically on the right side of the main frame. We’d also to (ideally) put all the methods from the calculate tab, and place them on the relevant tabs, instead of having a dedicated tab for each calculate function (if that’s possible).

* Calc Mesh – Change form to have limited options like read/calculate. Calculate will calc mesh as usual, but will save the results as tables and add then as attachments to the cont6 file. Read will simply read in those attached tables, and that functionality is already there (the reading in the tables part). * Have some way of allowing users to test their own cont6 files. One way is to modify our exiting test form and allow for the user to define their test their. They would need to specify the script that they want to run as well as the resultant object(s) that they want to test. If we give a list of objects for the user to select from to test, we need some kind of metric to determine the list of objects they can select from. Or do we just give the most common ones for their type of problem (stress/strains for BM, AP/ECG files for EP, etc).

  • Once the test is defined, it would become an attachment to their existing cont6 file, and then they can/should deposit the cont6 into the DB.
  • There should be a way of saving the state of the test inside this test attachment/object.
  • The test attachment/object should be standardized so that we can easily determine if any cont6 file contains it, so Continuity can readily test these files by using an automated approach (e.g., scan the DB and automatically test all files that have this test object)
  • When opening the test form, we should be able to detect if the cont6 already has this test object, and if so have edit/run buttons, otherwise just have create.

BUGS

  • Some image processing (connected component labeling) doesn’t appear to be working properly
  • Projection length bugs – color and “filter” both not working
  • Toolbar corruption bug still caused by new equations editor’s treecontrol. I was on the path to fixing this with: 
    • self.GUI.ROOT.slaves()[0].pack_forget() #just kill top
mb = self.GUI.ROOT.slaves()[0].slaves()[0]
mb.pack_forget() #menu bar kill
mb.pack(fill = 'both', expand = 1)

  • mb.children has two Scrollbar children, grid_forget() both of them. Also maybe mb.configure(height = 20)?
  • Electrophysiology Boundary Conditions bugs (talk to Jazmin)
  • Model Editor standalone mode (crashing when run outside of Continuity)

In Progress

  • New boundary condition forms and model editors
    • Minor changes to BC form to have tabs for displacement, forces and pressure
    • Initially, forms work the same as they do now (i.e., users enter the values)
    • A script will then assign these values to nodes
    • The script will receive ALL the data from the form, and will provided additional helper utilities that are applicable to each form.
    • Alternatively, in the script the user can call a model to generate the dependent values
    • The model would be written by the user in a regular model editor form. They would use ONE model editor form for composing several models, but the controlling script would call the one being used.
    • The new model editor form would just need to 1) Made the Parameter folder at the same level and Model 2) Either create a top level folder that all models can reside in, or simply allow new models to be created at the same hierarchical level.
    • As these can use state variables, the overall code gen/solving approach is similar to the Ionic model, and should be able to use that model for testing.
    • The scripts would (at least initially) reside in the Script Manager form and there would be templates for displacement, forces and pressure, but people would be able to modify and create new ones.
    • The template scripts would show the input/outputs expected (i.e., define the API), but the user can, of course, do whatever they want to them.
  • List Volume form will be kept the same, but the entries in the form are simply for listing purposes and are NOT used in the model For the pressure script, provide get_undeformed_volume, get_deformed_volume, etc functions which calculate volume as is currently done in the list volume form
  • Pressure form Remove the main drop down, and only keep the increment page and don’t def to 0.0 but keep blank, and then only have one line per element list