OpenCOR is a cross-platform modelling environment, which can be used to organise, edit, simulate and analyse CellML files.
Home Page: https://opencor.ws/
License: GNU General Public License v3.0
OpenCOR is an open source cross-platform modelling environment. Here are a few links, which you might find useful:
You might also be interested in our users and/or developers mailing lists, as well as in our published article.
Please contact us if you have any questions about OpenCOR.
Our core plugin on which every other plugin relies.
Starting from the COR-like view (issue #17), it would be good to go one step further, i.e. have a view like the COR-like view but without CellML-specific concepts such as public/private interfaces, encapsulation hierarchy and connections.
Currently, the GUI consists of different docked windows (e.g. the help window). These windows therefore have a title-bar even when docked. This title-bar takes space, so if we were to allow those windows to be 'locked', when docked, then we wouldn't have those title-bars and would therefore gain some space.
This relates to the simulation side of OpenCOR where it will be essential to allow the editing of simulation (e.g. start/end points) and numerical solver parameters (dependent on the solver to be used).
Consists of allowing the user to edit a CellML file using its XML code.
There are certain events (e.g. the dropping of a file, on the file organiser widget, which already exists) which would benefit from being mentioned to the user, but in a 'silent' way. One way to do this would be to have some kind of a message window for any message that might be of interest to the user, but which doesn't need to break the user's workflow.
As much as possible, it would be good if various features within OpenCOR supported the undoing/redoing of actions.
It would be nice to have the same shortcuts (e.g. Ctrl+C) for different windows (e.g. the main window and the help window). (This seems to be a bit tricky to implement, even when changing the value of QAction::shortcutContext.)
We have some code for a file browser, but it now needs to be made available as a plugin.
We need a plugin to get access to QJson (http://qjson.sourceforge.net/), so we can decode results of JSON-encoded Web services, such as the one that will get provided by PMR2.
Depending on the view in which we are (e.g. the "Raw CellML" view in the editing mode or the "Single cell simulation" view in the simulation mode), the menus should reflect the view in which we are. The reasoning for this is that menus used in an editing view will be of no relevance to a simulation view, and vice versa.
Some plugins have a dependency on other plugins. For example, the "Raw CellML view" has a dependency on the CoreCellMLEditing plugin which itself has a dependency on the CoreEditing plugin. The CoreEditing plugin will ideally offer menus that are relevant to any editing view while the CoreCellMLEditing plugin will offer menus that are relevant to any CellML-related editing view. So, when switching to the "Raw CellML" view, we have to take those dependencies into account.
Ontologies are critical to modelling and, as such, we should support them (through RICORDO; see http://www.ricordo.eu/).
cmgui (http://www.cmiss.org/cmgui/) is a powerful 3D visualisation library which would be useful to support within OpenCOR for the 3D representation of models.
Some potentially useful links:
As an extension of issue #1, it would be good to be able to track the different versions (nightly builds, beta versions and release versions) of OpenCOR and thus allow the user to go from one version to another.
Indeed, say that the user uses an official version of OpenCOR (version N) and that a nightly build (version N+1) becomes available. The user might then want to test version N+1, but then revert to version N afterwards (because version N+1 is too buggy, he would rather stick to an official version, etc.).
In other words, the user should be able to go forward, as well as backward, when it comes to the different versions of OpenCOR.
We have some code for a file organiser, but it now needs to be made available as a plugin.
QScintilla is to be made available as a plugin.
Someone should be allowed to run/pause/stop a simulation. When a simulation is paused, the user should be allowed to edit the model's parameters (see issue #29).
It would be good to have advanced metadata support so that, using domain-specific ontologies (through RICORDO), models can be comprehensively annotated.
SED-ML (http://www.sed-ml.org/) is a markup language for encoding simulation experiments which would clearly be useful to anyone using OpenCOR.
Especially for the analysis of files, it would be good to support plugins, so that the community can contribute to the project by developing plugins (e.g. a plugin to analyse cardiac action potentials and extract some key parameters from them ) and making them available to the rest of the community.
Right now, OpenCOR can 'C' parse a model that contains definite integrals, but then it won't generate any binary code (using LLVM) for it.
When deploying OpenCOR on Windows, the CellML files that are deployed in the models folder should be read-only, but they are not. This occurs using both the ZIP file and the NSIS setup program. (Everything works as expected on Linux and Mac OS X.)
Any decent application should have an auto-update feature and this is what this feature is about. It will clearly have to be platform-dependent, and should only update what needs updating (i.e. add/replace files, remove files, etc.).
By default, only updates for a release version of OpenCOR should be offered. However, the user should be allowed to update to a beta version or even a nightly build of OpenCOR, should he so desire.
A possibly useful resource is KDUpdater (see http://docs.kdab.net/kdtools/2.2.2/group__kdupdater.html).
This is a feature on which many software developers rely, and which would be equally useful to modellers and model users.
Considering the tree-like nature of XML files, it would make sense to have a tree-like view for a CellML file.
We can't expect people to only use OpenCOR, so we should allow the export of simulation results to the CSV format.
Any crash of OpenCOR should be gracefully handled, i.e. ideally OpenCOR would generate a crash report that the user could then email to us.
Note, however, that the 'issue' with such a feature is that if we want to make the report useful to the OpenCOR team, then OpenCOR will have to be built with debug information. The questions then are:
The user can add/remove graph panels, so we need a way to identify which graph panel is to be deleted. Also, this will be used to determine to which graph panel a curve is to be added.
Say you are in full screen mode, then exit OpenCOR and restart it. You would expect the full screen mode to be 'checked', but it's not which means that if you, say, press F11, then nothing happens. However, the second time you press F11, then OpenCOR restores itself from the full screen mode.
Everything in OpenCOR should be done through a plugin, even for the help.
QtMmlWidget is to be made available as a plugin.
As in COR and OpenCell, the export of a CellML file to various programming (e.g. C/C++, F77, Java MATLAB, Python) and word processing languages (MS Word 2007/2010 and TeX) is essential.
The idea is, as in COR (http://cor.physiol.ox.ac.uk/) to have a list of warnings/errors generated upon CellML validation. From there, the user can just double click on a given warning/error, and OpenCOR will highlight that warning/error in the corresponding view.
Drag and drop is now well supported in OpenCOR (between the file browser and file organiser widgets, as well as between those widgets and the central widget). However, it would be nice, when a file is opened in the central widget, if we could drag and drop its tab onto the file organiser widget.
When simulating a model, one should be able to edit a model's parameters (using a tree-like view).
By default, Qt binaries are released for Windows 32-bit. It might, however, be nice to have a 64-bit version of OpenCOR at some point, but this would obviously require a 64-bit version of Qt. This is all possible (e.g. see http://pinyotae.blogspot.com/2010/11/building-64-bit-qt-47-using-mingw-w64.html), but might be a bit involved. So, hopefully, Qt will at some point in the future release 64-bit binaries for Windows.
Analysis features will mainly be provided by the community through the use of plugins. However, it would be nice to provide one as an example. So, we could create a plugin for the analysis of cardiac action potentials. The idea would be to extract some key parameters from those action potentials (e.g. upstroke velocity, action potential amplitude, action potential duration at 90% repolarisation).
PMR2 (http://models.cellml.org/) is the official CellML repository. It would be good to offer access to it from within OpenCOR through web services, so that one can search, download, upload, etc. a model.
Unlike in COR where simulation results are always plotted against time, someone should be allowed to plot simulation results against any parameter.
It's very common for a modeller to run a model modify some parameter values, run it to steady-state, etc. From there, it would be good to allow the user to create a new or update the model based on its simulation results and current status.
On Mac OS X, to click on Cmd+M normally minimises the application that currently has the focus, but this doesn't work (anymore?) with OpenCOR.
The CellML API should be accessible through a plugin. In our case, since we don't want to have to build the API ourselves (too many external dependencies!), we should use the binaries provided by Auckland.
As in COR (http://cor.physiol.ox.ac.uk/), it would be good to have a simple way to edit CellML files (rather than using the raw view; see issue #16).
It would help the user if there were to be a search feature within the help window.
There are different ways we could edit a CellML file (e.g. issues #16, #17, #18 and #19). Another would be to have a graphical representation of a model, either in 2D (using SVG) or in 3D (using cmgui), and this based on the metadata/ontology information present in a CellML file. This would, among others require support ontologies (issue #12) and cmgui (issue #15).
The help window would benefit from an index.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
