This page contains various tasks to be completed now and in the future. Enhancements and bugs are listed here, bugs will eventually be in a database. Most of these are just random thought fragments that are jotted down as needed.



  • Allow user to select which dynamic model they are using on the Compile tab for the constitutive model form. If they select a dynamic model, then add the dynamic params to the exiting constitutive model list and also add in a Initial values tab with the dynamic model's conditions, and remove the initial values, set parameters tabs for dynamic model, and (change submit to save) -- not sure about the last one, what are we saving? There's a save on the compile tab
  • Convert Circulatory model to sympy
  • List strains at nodes, similar to Lstrain, but for nodes, not gauss pts (see Roy), render surface includes this calc
  • Add the ability to solve at gauss points. Need to be able to select the gauss point from the parameters tab. Initial thought is to add a gauss point field editor that can read in a gauss point file, show the column name and then allow the user to select which column they want to compute at
  • For non-GUI runs (e.g., ContinuityMultiCore.bat, etc) we need to issue a warning that we're missing the independent variables. We currently throw up a GUI prompt and wait until the user accepts the warning. However, execution of the non-GUI script stalls at that point. The user needs to open the model in the GUI and then have Continuity add the independent variables.

  • It's been reported that you can't link a new Dynamic model with an existing Constitutive model and that you have to build a new Constitutive model, is that true?


  • Keep singularites at least on EP, but include 'for single precision' in the desc


  • Add ability to do both 2 and 3D elements in landmarks
  • Update Mesh->List->Nodal Field to allow for the user to choose which column to read in, and allow them to choose which basis function to use. Some of this is incorporated in the script version of the command.

  • Add color to elements/nodes -- keep to mesh/render
  • On Elements form, add Element number next to Element Label, as is done in Nodes form
  • Add 'Grid' radio button on render surface form to be able to render the values without interpolating them via the CalcConjugateBasisField call.

  • Add Output Variables folder to material coordinates model editor and allow for people to use that in the same way that BM does. At the same time, change the sympy to C code generation to use the same methodology that BM and EP use.


  • Get it working


  • Update the web code on rocks-86 to work with cont 6.4, and not just 6.3 – the code that displays the list of models users can download (it’s currently just displaying all models with 6.3 in their names)
  • Start the CMRG/Continuity website when lys boots up
  • Finalize samba directories/archival process for CMRG users on lys


  • Figure out what/if any differences there are to a start-up stored_data to a reset stored_data -- find best way to truly reset server. It's been a long standing suggestion to fully restart Continuity after doing certain tasks (e.g., compiling) as opposed to just resetting the server.
  • On model editor compile tab, allow a user to load in their own C model, and use that code when we compile
  • Change edit basis form to be in nodes form, put XI locations on calc mesh
  • Allow point/data to be saved in cont6 file (e.g, the connected nodes points) -- edit images interface
  • Define the revision of Continuity in a single place, and not have it hard coded into the code
  • Install DB component needed for Mac and Linux – apsw, needs to be compiled with: < --enable=fts3 > build flag,

  • Add value checking, and actually store/use the numbers in the Scale Factor entry field on the IC/Parameters tab of the eqn editor
  • Add ability to 'watch' variables from eqn editor -- at least a simple print option -- Robert has it working for Bm Constitutive models
  • Only use dist_superlu, get rid of serial (or course only if this works and doesn't slow down considerably on single cores)
  • Standardize where new windows open in Cont -- They should all open within the currently opened window. Most of the windows in the toolbar open outside main window.
  • Store models (eqns, and binaries) in both remote and local DBs. Initially just the remote one, which will allow us to define the method we want to use, then the local one. When opening a model editor, the list of models will be taken from the DB, and only list the models that JUST have the law defined in it (i.e., no nodes/elements), which should limit the number of duplicated models. The client will have to tell the DB, which type of server it is connected to so we only show compatible binaries. Might want 3 objects to keep track of: equations, binary, and parameters. Know the status of these, and only submit the changed object to the server.
  • perhaps separate field vectors from the node form -- if we add a field vector into the nodes form the server will reset and we'll lose the solution -- how to handle, and not loose solution data when resetting the model
  • Add ability to create a new save folder from the save gui
  • Get parallel working solidly, especially for EP, which isn’t working as of now – still wired for radau.
  • Redesign the make system so that it’s more standardized: ./configure, make, make install should be all that is necessary (requested by nbcr)
  • Want to add coordinate system editor, need to use 4 primary fortran functions: get_yfromx, get_dydx, get_dy2dx2 and get_dxdy. get_dxdy doesn't exist, but can be made from deriv_xy. Also, want to change how get_d2ydx2 works: currently it calls d2zx to do the calculations, but want those calculations to be within get_d2ydx2. Simply have 27 in line assignments would suffice. All that, and also making use of the fortran functions: mult33 and inverse, should give us all the functions we need. Coordinate reference: X = undeformed world coordinate, x (Z in python/fortran code) = deformed world coordinate, Y = undeformed Cartesian coordinate, y = deformed Cartesian coordinate.
  • Remove reference to JTYP3, and replace it with a function that will do the transformation instead
  • Automate (or at least beef up the documentation) to get the Mac environment set up to compile models, also find out what is necessary beyond the base OS to be able to compile/run (definitely need gcc and X11, anything else?) Ideally do this when starting Continuity, not necessarily on install -- keep the procedure the same for all O/Ss, as we do everything post-install on Windows.
  • Add tests that will test the compilation environment (i.e., can we compile and run a given model on a system with known installed compiler tools).
  • For Fitting we currently use the geometric data structures, it might be better to use the dependent data structures during matrix assembly as biomechanics does, and then redo the fitting constraints form to be more like the biomechanics boundary conditions form, and then also modify the Fit form in how you select the variables/data your are fitting.
  • When fitting modification is working, be sure to wrap the last remaining Fortran calls in p_fitfldassmbl.f (i.e., xpxe, zder, zdes) and then call those from python and no longer call p_fitfldassmbl
  • It might be helpful to list ALL derivatives when doing a Mesh -> List -> Element Points (lixj). That listing currently call Mesh.GetElementPoints which eventually calls p_getxj that returns what is listed from that form. It can be easily modified to get all the derivatives at each (nu), and then it'd just be a matter displaying them in the form in a reasonable manner. Some suggested labels are: xj(1), dxj(1)dxi(1), dxj(i)dxi(11), dxj(i)dxi(2), ... , dxj(1)dxi(123) or using dxj_1dxi_11 or dxj(1)dxi_11

  • Have the open/save GUI windows be native in Mac, as they are for Windows. It seems like from:, it's possible, but on first attempts getting: Error: (-1713, 'no user interaction is allowed') and need to look into what it takes to get around that. One suggestion is to rebuild python with the following flags: ./configure --enable-universalsdk --enable-framework

  • Just a note on Fitting: Chris was having issues fitting his data to a mesh and was running into memory issues. He found out that the main way around this is to continue to refine his mesh, as there appears a point when there are too many data points in an element, which the fitting engine doesn't like. He also seems to think that trying to only fit a couple of elements in his mesh, as opposed to fitting everything, caused issues as well.
  • Change model editors in how they use field values on the parameter tab.
    1. Instead of listing all of the derivs in the 'For default values use' dropdown, only show generic field derivs (e.g.,Field Deriv wrt s(1), s(2), s(3), s(1)(1), s(2)(2), s(3)(3) the angles (fiber, rot, etc), and gauss point table, and later xi table.
    2. When selecting a field deriv, the column next to this drop down, would then show the currently available fields (e.g., Field 1, 2, 3), allowing the user to select the one they want to use.
    3. If a user selects a gauss point table, the next column would then show a Browse button where someone would then select the file containing the gauss point infomation, and then have a nice way of handling how to allow the user to select the column they wanted to use. One approach could be that after the user selects a file, the header line (assuming one is present) is read and then the list of columns would be shown allowing for the user to select the column they want to use. If one of the columns matches the parameter name, show that one by default.
    4. Xi table specifics to be determined later.
    5. Retain the existing 'value' option in the listbox, and that'll still be the default selection
    6. The suggested use of this is that at a send, the client reads the file and then sends data to the server -- a data structure needs to be defined to account for this, combining with rpar or something new entirely.
    7. Later, does server cache tables in a temp directory e.g., bmpar_mynewpar.xls?
    8. An example data structure could be: [ne, ng, np] - where ne is element number, ng is gauss number and np is param number
  • Adarsh has reported that occasionally (not all that often at least for now) that when running in parallel and doing a Send from a script resorts in an error and he's suspecting it's due to a race condition of some sort....However having exact error messages could help diagnose this further.
    1. As we now include msys with Continuity, when we install new versions of mgltools, we should make a copy of their existing .profile file so they don't have to figure out what was in their old .profile file. This is primarily for developers who need to specify things to get Continuity to compile (i.e., IFC_LIB_PATH, etc).
  • Refactor p_fitfldassmbl.f to not call c_fortran_dgssv_mod.c (i.e., SuperLU), but instead have Python call SuperLU.
  • Change Mesh -> List -> Elements to incorporate the changes in how the scale factors are changed -- see Matt for more info, or add it into the Mesh -> Edit -> Scale Factors command

  • Unit Tests - testlongsolution results differ between mac and windows, is that due to ifort version difference?, build2D_ep not working.
  • Create unit test for testing numerical results that get sent to renderer.
  • Create unit test for testing heart vector (for EP problems).
  • DB: All a user to deposit a model into the database from a script.
  • DB: In the Retrieve From, the title doesn't change when clicking on different versions, and the model id isn't always correct when there are multiple versions of a model.
  • In model editors, manage how C functions are called to make them look more like math to the user. Right now, eig3 is the onyl C function used, and it's return value is void, so the equation in the model editor looks just like a function call (e.g., eig3(Symbol('T'), Symbol('T_M'), Symbol('T_p'))) but it would be better to have it look something like: T_p = eig3(Symbol('T'), Symbol('T_M')). The idea of having a C function type in the model editor shouldn't be necessary for C functions that are included in Continuity, but if we support people providing their own C functions, having a C function type might be necessary. For eig3, since it computes eigen values and eigen vectors, but generally either values or vectors is wanted, perhaps having separate functions for each value would be better.
  • Notes on unit conversions: current thoughts are to allow units differences between left and right side of equations, but all terms on right hand side should use consistent units, so that the resulting equation could simply be: a = unit_conversion * (b + c), instead of having a = unit_conv*b + unit_conv+c
  • Note on allowing people to enter their own code in model editor: 1) for eqns, have new var type of 'code', and for simplicity just allow people to write their own C code which gets inserted into the generated code 2) for parameters, in the drop box, have new choice of 'code' and allow people to enter python code which would control how the parameter is computed or even updated.



  • 3/20/2017: After a biomechanics solve, I discovered that the deformed mesh elements must be rendered before rendering any field (e.g. stresses or strains) on the deformed surface. The field will render, but only on the undeformed mesh. Also, if you render the field first, then trying to render the deformed elements will only render the undeformed elements. Use the prepared model at the end of the Continuity/Documentation/GettingStarted tutorial to test this. Biomechanics->Solve nonlinear...->Solve... Then Biomechanics->Render->Surface... -Eric Carruth

  • Look at ODe solve times (see Roy), eg: solving odes from 0.000000 to 2.000000
    time now = 4.0
    Getting initial residual...
    solve 1st active 1/2 time step whose result is y
    solving odes from 2.000000 to 4.000000
    solve 2nd active 1/2 time step whose result is y
    solving odes from 4.000000 to 6.000000

    Should we really be solving up to step time 6?

  • Output variables from List Stress Strain don't always show the new output variables put into the eqn editor (Roy)
  • In (around line 332) it only initializes when time1 = 0, but it might be better if that was actually the first time step in the form (i.e., time_t0)
  • Roy’s script doesn’t work in parallel, but does in serial (script: calculate strains and update fields with them, and then extract and put back values in fields)
  • When listing stress/strains if you enter xi1: 4, xi2: 1 and xi3: 1, you get a "KeyError(1, 3)"

  • Boundary conditions are always taken from initial conditions -- see Roy or Adarsh
  • Forces are multiplied by time (t) -- See Roy or Adarsh


  • EP model editor form -- when re-selecting an already submitted model, it chokes
  • Re-rendering issue?


  • 3/20/2017: If fiber/sheet/normal angles are defined in a simple mesh (for example, a prolate single ventricle), and that mesh is then refined, the fiber angles all become 0 unless the fibers are rendered before the refinement. The Continuity/Documentation/GettingStarted tutorial is a good example of this. -Eric Carruth

  • In rendering, it seems like on Windows 7, at least for certain renders, if you change the range of values to plot, values that are outside of that range do not show up (e.g., initial values are 0 to 1.5, and then it's changed from 0 to 1.0, the numbers > 1.0 would not be rendered). See Adarsh for more details.

  • When choosing quadratic Lagrange basis functions, there is no update to the Elements Form for defining the local to global transformation that would account for the extra nodes per element. There is also no option for bi-quadratic or tri-quadratic basis functions (2D, 3D).


  • It seems like you have to submit both the constraints and weights forms before fitting, as the fitting method expects them to be defined, and they aren't unless people submit those forms.


  • When hand editing a model's *xls file, the parameters don't always end up in the rpar list in the correct order, Cont should be smarter about the order in which the params are listed verses the eqns. -- Solution: make sure the Import function goes through the same pipeline as the eqn editor, i.e., create required parameters based on the ones used in the eqns, and only use the values from the file, not necessarily using all of the parameters in the file, ONLY the ones that the existing pipeline puts into the parameters table
  • Changing opacity of surface doesn't seem to work
  • Roy's client/server bug: When I run a Continuity client-only on my mac, and connect to a continuity server on the granite, and I shut down my client after connecting to the server (after having done some stuff), the client shut downs fine, but the server doesn't and gives error of CheckSum Error returning partial data. This always happens and I'll have to kill the server.

  • Investigate the Fortran compiler error on lys2 -- only seems to happen when doing a fresh make, doing another make 'fixes' it
  • When compiling with --with-g95 flag SWIG isn't found under windows
  • When running batch jobs (at least on windows and linux) it seems like they do not cleanly exit, and need to be manually killed. Adarsh has been seeing this consistently on Windows. For example he'll run a job with 10 threads, and at the end of the script some will exit cleanly, but others won't.
  • If the first time you compile anything within Continuity is a dynamic model or a dynamic/constitutive model, Continuity will not run autoconf/configure things. We need to account for that, as the first compilation (as mentioned above) will fail.
  • If you export a model from a model editor that doesn't have any parameters, the parameter folder will not be exported, and it will not be created if you import that model and add parameters to your model.
  • There is a difference in the table produced by "List" versus using "Biomechanics > Render > Surface..." and then choosing "Calculate and Save Stress/strains to File" under "Gauss Point Field Values". The values are shifted by one column with respect to the column headers. There is a column header "pressure_coupled" in the table produced by the Gauss point field values that shifts the subsequent column headers to the right.