Continuity 7.0 Reengineering Plan

Outline: March 25th, 2017

Server

  • Deprecate support for server on Windows and MacOS so that we can focus effort on cloud-based Linux server and take advantage of numerical libraries only available for Linux
  • Modify Mac and Windows clients to connect remotely to default cloud server. Start by testing AWS EC2 for hosting since it should bypass the security problems of using Python for client-server messaging and it is scalable enough for small or large, compute, memory or GPU intensive problems. We can set up a free account for testing.
  • Build a priority list of Linux-based numerical libraries that we can use to optimize numerical performance. These likely will include

    • PyTrilinos (already being used by Linux version)

    • FEnics
    • StochSS
    • GPU optimized numerical libraries?
  • Deprecate support for curvilinear coordinates. These are really only useful either for toy problems or generating simple shapes that eventually get subdivided and converted to Cartesian coordinates. This functionality could be recapitulated by making some simple client plug-ins for building simple models interactively. This will allow server code to be dramatically simplified and hopefully optimized.
    • Specifically, look for the integer variable JTYP3, which is currently 1-5 for the five different coordinate systems. This would now always be Cartesian Coordinates (JTYP3=1).
    • On the client side, this means the Mesh Edit Coordinates … command would go away

Client

  • Migrate client to Blender using Blender UI
    • Start by migrating all graphics (i.e. “render” commands) to Blender.
      • Note that the Continuity client really only has fairly limited graphics capabilities: It can render lines, surfaces, texture-mapped surfaces, points (spheres), vector fields (e.g. fibers as short line segments without arrows), and tensor fields (the glyphs used for diffusion tensor field rendering). Of these 90% of what we do can be achieved with line, surface and text-map rendering, all of which we can already do in Blender using Continuity data structures. So the major task is really just coming up with an API for sending Blender the data structures it needs for specific Continuity rendering needs.
      • We can deprecate quite a bit of server side code as well as client code when we do this, but I suggest not trying to port server side code to Blender, at least not yet. In other words, Blender should not need to know about Continuity variables and interpolation functions etc. It should just be a viewer. Continuity can just send a label with the data so the user can tell what variables each rendering in the scene is depicting. In other words, render stress, or render strain or render field would not require separate Blender functions. Continuity would just be sending different data to the same Blender texture-mapping plugin that would unpack the data and render it using existing Blender graphics.
        • Where possible make use of available Blender functionality or plug-ins rather than trying to emulate Continuity which has some very old and inefficient graphics. We may later find that we can optimize some Continuity server side computations using more advanced features of the Blender geometry engine.
    • Create (open source) plug-ins corresponding to menu modules of Continuity
      • Start with the Mesh module and then proceed to Data (Fitting), Electrophysiology, Biomechanics. Develop a strategy to do this conversion incrementally, adding functions to Blender and removing them from the Continuity client in steps.
      • Do not try to port over large forms such as Nodes, Elements, Boundary Conditions and the various model editors that already have a “Table” interface. These forms are the ones with a button like Import/Export or Import/Export/Graph. Instead, make simple versions of these forms that allow Tables to be imported (or exported). It could still be possible for the Blender client to change the data in these forms but this would be done interactively, e.g. by moving nodes or subdividing the mesh, just not by typing numbers. There will still be a few buttons (such as “compile” in the model editors) that are needed, but the new version of these forms in Blender will be very simple to implement.
  • EITHER Determine whether large forms and editors can be opened from within Blender
    • To preserve the larger interactive forms and editors that we currently have in the Continuity client. If Blender can open and co-exist with the large Tkinter editor windows in the current Continuity client, then a Blender plug-in would only need to open the form and maintain the state of the form data rather than reimplement the big editor forms.
    • The other large client forms that could be handled this way are the database interface forms.
    • Once all of the important client functions have been migrated to Blender then the client-server middleware in Continuity can be run through Blender.
  • OR Convert large forms and editors into lightweight apps

    • To preserve the larger interactive forms and editors that we currently have in the Continuity client, come up with a way to redeploy the Python code for these forms as standalone apps that simply read and write text tables or send their data to Blender or the server. One cool way to keep these apps together would be to embed them in an IPython Jupyter Notebook template, which would then provide users with a way of documenting and sharing their models. Think of this notebook as the new web-based portable Continuity data and model editor. The Blender plugins would serve as the Continuity viewer and command client. Note that almost everything the client currently does can be scripted and commands are equivalent to a scriptable sequence. This should be reflected in Blender, i.e. everything the UI plug-ins do should be scriptable.

    • The other large client forms that could be handled this way are the database interface forms. The major issue with this is that these forms up- and down-load Continuity binaries. This could be mediated by the forms talking to the database and continuity servers via the existing middleware running as a helper app (see below).
    • Once all of the client functions have been ported to Blender or standalone editor apps then all that would be left of the Continuity client would be the client-side middleware that talks to the server. It would be interesting if this middleware could be run as a helper app that either the iPython Notebook or Blender could use to talk to the server. A variation on this idea, would be to run the middleware as a Blender plugin, though this would mean that the Notebooks could not talk to the database or compute servers without Blender being installed and running.

  • A significant amount of the existing Continuity client such as the OpenMesh controller, DejaVu GUI, Stereo viewing, grid/Volume rendering, etc will simply disappear as part of this re-engineering. For each existing client function, the decision will be whether to (a) convert it to a Blender plugin or command, (b) convert it to a standalone app or form that could be executed from a script or Notebook, (c) some combination of (a) and (b), (d) replace it with a very lightweight equivalent such as a simple text input file or script, or (e) discontinue it. The result should be a much more manageable, lightweight, flexible and extensible client.

    • It might be a good idea to experiment both with Blender plug-in UIs and standalone editors invoked from a Jupyter notebook to see which is smoothest before deciding where to draw the line between Blender and separate editors.

Distribution

  • Everything should be in GitHub, possibly though not necessarily as separate projects for the Compute Server, Database server, Blender plug-ins, and lightweight form/helper apps.

  • Play with SimTK.org to see if it will simplify the distribution of source code and binaries and the management of users and distribution etc. For now, make all the client side and database source code open, but not the computer server source.

  • We have an existing SimTK Continuity project at https://simtk.org/projects/continuity

  • Assuming the registration or membership framework provided by SimTK is sufficient, then use this to replace the current registration mechanism which has never worked well. This has now been confirmed.