skip to main content
OSTI.GOV title logo U.S. Department of Energy
Office of Scientific and Technical Information

Title: Report of the IMFIT Advisory Committee from the Meeting of 9/16/08 at General Atomics

Technical Report ·
DOI:https://doi.org/10.2172/945870· OSTI ID:945870

The Committee commends and thanks the presenters and GA for providing clear and informative presentations. We present our responses to 5 questions raised in the Charge, as well as additional comments that may be useful for the project. (Question 1) The IMFIT framework is based on PYTHON and CCA; can IMFIT meet its long-term goals with this choice of language for framework? Our first recommendation is to change the terminology; it appears that the project is not really utilizing CCA (Common Component Architecture). The project is really about using Python to organize workflow among components that are spawned as processes via pipes from Python. We suggest that in describing the project, the team drop the designation 'CCA' and simply state that the IMFIT framework is based on using Python to control workflow among components. Concerning the specific question: we understand the principal goal of the project to be the development of an easy-to-use tool that efficiently integrates different physics modules to support experimental data analysis and modeling. Yes, Python and the workflow-based framework are appropriate choices for meeting this objective. The Committee, in examining the goal, discussed whether the IMFIT project was duplicative of other projects; there are several others in the U.S. and elsewhere with integrated modeling goals. In particular in the U.S., SWIM, PTRANSP, and the proto-FSP's. However this project occupies a reasonably unique niche through its emphases on integrating experimental data, use of existing components, its near-term focus, and the extent to which is targeted at experimentalist users. (Question 2) Will IMFIT benefit from the additional use of an interoperability language for framework such as BABEL? No, IMFIT is not really doing inter-language communication. In particular this will be the case as long as inter-component communication is via files--and that's OK so long as you aren't doing lots of short steps with communication at each step. (Question 3) IMFIT GUI is based on the public PyGTK toolkit; will IMFIT benefit from the additional use of other public Python graphic toolkits such as wxPython that is a cross-platform wrapper, or PyQt, or a commercial package such as IDL? PyGTK seems adequate for now. The team needs to decide if it needs more capability. Avoid licensed software that interferes with portability and the open-source goal (and thus in particular avoid IDL). (Question 4) Will IMFIT benefit from using a XML-RPC as alternative to sending files thru sockets? IMFIT could benefit by adopting some kind of self-describing format, such as XML or HDF5, but data can still be sent over sockets. This is part of a broader question: 'Should IMFIT adopt some kind of standard for communicating data between components?' To do anything other than what is done now requires modification of individual components (or convertors/wrappers). But moving to a self-describing standard is a good idea, which should be considered. You don't need to impose a standard, but you could decide on one and move toward it gradually, as the architecture doesn't impose a standard. But whether you adopt a standard and the pace of moving toward it is up to you. (Question 5) Will IMFIT benefit from any other available computational tool? (a) IMFIT would benefit from fuller use of an already incorporated tool--python language in the task execution specification, to enable desired features like branching; (b) If there is a high degree of data hierarchy, IMFIT should explore HDF5 as well as NETCDF and compare; (c) IMFIT would benefit from moving toward common data standards; (d) It would be useful for the IMFIT team to monitor developments in related projects such as the proto-FSP's and PTRANSP to ascertain if there are potentially useful tools.

Research Organization:
Lawrence Livermore National Lab. (LLNL), Livermore, CA (United States)
Sponsoring Organization:
USDOE
DOE Contract Number:
W-7405-ENG-48
OSTI ID:
945870
Report Number(s):
LLNL-TR-408094; TRN: US0901253
Country of Publication:
United States
Language:
English