CIBC:Core:BioPSE
From NCRR Biomedical Software Development, Engineering, and Dissemination Wiki
Contents |
Background
This section of the Wiki is dedicated to describing the CIBC goals for developing the software architecture and infrastructure. The grant text contains a starting point for this discussion so please read that for an introduction.
Requirements list
For each collaboration, list the technical specifications of the software needs from the specific perspectives of: a) control structure, b) data representation, c) user interface, and d) algorithms. Try and convey where there are existing solutions and where there is great need for new or better solutions. If possible, list where SCIRun covers any of these needs now. Try and be clear about which parts of the technical needs are development projects, i.e., the methods are known and just need implementation, and which parts include significant research.
Paring Down of SCIRun
In an effort to reduce the size and complexity of SCIRun, in November, 2005, we began a project to trim down the code, increase its robustness, and enhance portability. See the link before for details.
Agenda Next Management Meeting
[1] How can we better separate our SCIRun development from the rest of SCIRun. (a) Could we branch of our own development tree, and then only distribute our own tree which we then could make far more lightweight? (b) Could we fix the few things in the Core and then use our own packages to customize SCIRun (What needs to be done to the Core to make it work sufficiently for us to work with) (c) do we want to keep all developments in the same tree? Do we know what NCRR-exec wants in this regard?
[2] What do we do with the BioPSE package? It has a lot of not well maintained code. Currently Frank is updating the FEM stuff, but that actually should go into the Core. Who is using the BioPSE package, apart from the FEM stuff I don't see many of the collaborations using it.
[3] I am working with Micheal on cleaning up some of the Core and fixing some problems. I would propose to go ahead with the Algorithm/Module separation. It is not such a big project and will improve the Core in terms of usability and will formally separate Core and Dataflow in a nice way. I talked to Micheal and he seems to agree it is not such a huge effort and should be easily doable.
[4] Topics we discussed last time but did not get to decide on: What is the future of dynamic compilation? How do we set up regression testing? What do we do with the memory management? My suggestion : first do algorithm separation => then regression testing on an algorithm basis => then deal with dynamic compilation => then deal with the memory management issues.
[5] I talked to Micheal and McKay and they are looking into tracing the problems with the viewer, which is still crashing. McKay will get back to me on how to get better stack traces on my Mac and how to setup my build to contain more debugging information, so he can use that information when I succeed in crashing SCIRun again (I guess I have become an expert in crashing SCIRun :)). I will ask Frank as well to build with a stacktrace option, so feedback to the developers will be more complete. This way we could collect more SIGBUS crashes and at least pinpoint the functions where this occurs, which be possibly the best help to the developers. I guess this would be my suggestion to further improve debugging.
[6] When do we expect to have a new stable version? I was not really impressed with 1.24.2 as it crashes in the viewer a lot, which is not a good sign for a visualization package. Hence we haven't released a stable version since last April. We still have collaborators, so perhaps before we remove the dynamic compilation we could at least have a kind of 'beta' release, the collaborators can download for the few projects in which we are already attempting to use SCIRun.
[7] I am planning to write some modules with Frank to smooth a linear model into a quadratic or hermitatian mesh. Using a C1 constraint and a local curvature threshold we hope to make a module that can translate models like the Utah torso into higher order versions. The reason is that there are no good tools for this out there and that such a scheme is easy publishable. Although it might not directly impact the current collaborations, if we have tools for making models higher order it will get us a publication and we could present it at a conference and will give SCIRun another feature other software packages do not have. Furthermore, we could apply these techniques in Bruce's modeling of the heart. Visualy the higher order models look more impressive too. Any suggestions?
[8] CMake/Dart demonstration.
[9] Interpolation/Mapping/Distance. It would be nice to extend the basis classes with a projection operator to find the point to the closest to the element. Similarly it would be nice to have a boundaing box (A lot of the algorithms make use of a bounding box to see in which grid an element is located, this does not work anymore as the estimated bounding box is flawed). Interpolating between to close surfaces does not seem to work as well. Currently a linear interpolation is used if the node where we need an interpolation is inside the volume, however if it is not we do a closest point search. The latter will be flawed in certain geometrical circumstances, e.g. a triangle can be right underneath the interpolation point, but its center can be further away then a neighboring triangle. This leads to confusing situations. Functions like direct interpolate do not use the new basis functions. Hence we should start thinking on how to improve this and make the interpolation/mapping functions more coherent.
