Difference between revisions of "User:Jmandel/WRF-Fire VisTrails wishlist"

From openwfm
Jump to navigation Jump to search
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
==Summary==
 +
At the teleconference June 24 2010, we have agreed that
 +
* SCI will keep the information what exactly to do and where the files are as howtos on the wiki
 +
* SCI will output a NetCDF file with only the arrays as processed for visualization, for diagnostic purposes
 +
* UCD will communicate requirements for a custom visualization tool using VisTrails and CrowdLabs
 +
 
==Jan's wishlist==
 
==Jan's wishlist==
  
===Stabilize the software===
+
===Easy start===
I think the following would really help to make it easier for a user to use the software.
+
I think the following would really help to make it easier for a user (especially a novice) to take advantage of the software.
# all up to date files (anything extra that is not in stock VisTrails distribution) identified and publicly accessible (git repository, tarballs) and best linked from the Howto
+
# up-to-date at least the first part of [[How to visualize WRF-Fire output in VisTrails]] (before the server), good even for a novice, and noting specific versions known to work
# up-to-date [[How to visualize WRF-Fire output in VisTrails]], good even for a novice, and verified to work with those files and noting specific versions known to work
+
# all up to date files (anything extra that is not in stock VisTrails distribution) identified and publicly accessible (git repository, tarballs, package files in vistrails, crowdlabs), explained in the Howto, keep track of versions
  
===Fine grained workflow and NetCDF utilities===
+
===Creating visualization===
This is a natural for a VisTrails workflow. But I need standalone command line versions of the utilities also, to be included in the WRF-Fire repository, which does not depend on VisTrails. The format of the intermediate files should be NetCDF so that the files can be easily manipulated by other software we have, in particular examined in Matlab.
+
* Tell SCI folks which arrays to support
# reduce the wrfout files to NetCDF files that contain only the variables needed
+
* SCI will build a custom visualization too, requires close communication
# add to the NetCDF files the node height variable computed from other fields
+
* Wiki how to use kept up to date
The follow-up tasks are then
+
* Long-term solution
# convert the NetCDF files with the height variable to VisTrails format and visualize in VisTrails
+
* Need howto should be for someone who has fresh installation
# convert the NetCDF files to VAPOR .vdf files and visualize the .vdf files in VAPOR
+
* VisTrails will dump also the NetCDF file with arrays that actually are visualized (and no others, to compress size) and the computed atmospheric nodes elevations. We'll use those files for input to Matlab and VAPOR for diagnostics. It would be good if the generated netcdf file is compatible with the wrfout file and can be used as the VisTrails input instead of wrfout.
  
 
===Other===
 
===Other===
 
* [[User:Jmandel/WRF-Vistrails user interface suggestions|User interface suggestions]]
 
* [[User:Jmandel/WRF-Vistrails user interface suggestions|User interface suggestions]]
* [[User:Jmandel/WRF-Fire-Vistrails difficulties|Finding the right files]]
+
* [[User:Jmandel/WRF-Fire-Vistrails difficulties|Difficulty finding the right files]]
  
 
==Jon's ideas==
 
==Jon's ideas==

Latest revision as of 08:44, 25 June 2010

Summary

At the teleconference June 24 2010, we have agreed that

  • SCI will keep the information what exactly to do and where the files are as howtos on the wiki
  • SCI will output a NetCDF file with only the arrays as processed for visualization, for diagnostic purposes
  • UCD will communicate requirements for a custom visualization tool using VisTrails and CrowdLabs

Jan's wishlist

Easy start

I think the following would really help to make it easier for a user (especially a novice) to take advantage of the software.

  1. up-to-date at least the first part of How to visualize WRF-Fire output in VisTrails (before the server), good even for a novice, and noting specific versions known to work
  2. all up to date files (anything extra that is not in stock VisTrails distribution) identified and publicly accessible (git repository, tarballs, package files in vistrails, crowdlabs), explained in the Howto, keep track of versions

Creating visualization

  • Tell SCI folks which arrays to support
  • SCI will build a custom visualization too, requires close communication
  • Wiki how to use kept up to date
  • Long-term solution
  • Need howto should be for someone who has fresh installation
  • VisTrails will dump also the NetCDF file with arrays that actually are visualized (and no others, to compress size) and the computed atmospheric nodes elevations. We'll use those files for input to Matlab and VAPOR for diagnostics. It would be good if the generated netcdf file is compatible with the wrfout file and can be used as the VisTrails input instead of wrfout.

Other

Jon's ideas

A couple of ideas that could help with usability and development.

Configuration parameters

Trying to customize a simulation by setting defaults for input ports is awkward and becomes almost impossible to manage when there is a large number of options in a workflow. I'm wondering if it would be possible to make some sort of a default configuration dialog that would pop up when running a workflow. Something like a standard configuration widget that contains all unconnected input ports that you can see and modify in one place.

Even better would be something like a module that you can place in the workflow with one output port. When you connect the output port to an input with a basic class (float/int/file/bool, etc.) that input is added to the configuration dialog with an appropriate gui element (for files, a string input with a button for opening a file dialog, etc.). Maybe multiple configuration boxes in the workflow could create individual tabs in the dialog.

Subworkflows

The problem with the workflow containing too many boxes is it becomes overcomplicated both to understand what it is really doing and to find what it is you are looking for. I'm aware that there is support for grouping of boxes and subworkflows; however, the problem with this approach is that all of the input/output ports get combined into a single box and (as far as I can tell) there is no way to figure out what each port does. Perhaps a way to annotate ports would help.