The purpose of this survey is to systematically collect Focal Point feedback on the Graphic Forecast Editor (GFE) system and Rapid Prototype Project (RPP) OVER THIS PAST YEAR of 2001. It is important that you provide your own candid responses to these questions in order for us to objectively assess the current state of the GFE and RPP. Your names will be kept confidential and will not be associated with specific responses. We appreciate your time and consideration in providing feedback that will enhance future system development. Feedback from this survey will be compiled by the FSL Evaluation Team and discussed at the next GFE/RPP meeting in November.

We are interested in all of your comments, so feel free to add any remarks you consider necessary to amplify your responses.

If you are unable to complete the survey in one sitting, be sure to press the Save Button. Then you can restore your existing answers for later completion using the Select Site/Name Pull-Down Menu and then selecting the Restore Button.

1: Which version of the GFE are you currently using in your office? (Refer to the GFE->Help->About menu).

I was assistant starting fall 2000, and then became the Focal when Jeff Manion went to CRH this summer.

icwf since 1991; gfe (in ifps since 1999... or maybe 1998);gfe in Linux (RPP) since Jul. 2001

3: Briefly describe how the GFE has been used at your site during this year's RPP (e.g. review/evaluate GFE software, generate operational products (if so, what products, how many, and how often), develop modernized products, etc.).

The RPP was used to train the staff in using GFE and is now being used operationally to forecast grids for all public weather elements out to 7 days. We are also generating graphics for Max Temp Min Temp and PoP out to 7 days and sending these to our website. The graphics are minimally compliant with Section 508....by clicking on a county in the graphic you are linked to the graphical RDF. We are currently having a problem with the ftp process from our RPP to our web site....not all graphics are consistently transferred during the ftp. As soon as we resolve this problem, we will make the links to our RPP produced graphics public. In addition, to the RPP workstation used operationally, we have a second RPP workstation used for development purposes (smart tools, smart init, config, etc.)

We have been using it operationally ever since we got AWIPS 5.0 in January 2001. i.e. used for every single forecast package we issue. We have been issuing numerous images to the home page. Jeff developed few different products such as Probability of 1" snow, and wind chill (before this became a factory setting). We have also been using our system for training much of Central Region, by hosting the IFPS focal points at our office.

All meteorologists went through training I developed (SLC job sheets) in May, 01. We began operational production of Air Quality grids and products, and SLC's Flash Flood Potential (FFP).These products were operational for many years, but we began generating them from grids, and developed new ways of presenting or disseminating the data. For the air quality elements(mix depth, transport wind, clearing index), GFE has allowed us to develop these products from a more rigorous and scientific model database rather than just looking at a couple of soundings and the synoptic pattern. For both air quality and FFP, the GFE has allowed us to create graphics and more complicated text products with relative ease from the grids. From the forecasters perspective there is very little effort in generating these new products. The effort is in focal point duties and the process is practically invisible to the forecasters. As an example: Our air quality customer who regulates open burning for all of Utah has developed 15 airsheds for burn/no burn decision making compared to the old system of 3 large air quality basins. The potential workload increase of typing forecasts for these 15 airsheds versus 3 basins was very large. Using the GFE gridded database, I was able to easily develop graphical and text products to satisfy the more detailed forecast requirements of our customer. The change was practically invisible to the forecaster and they can concentrate on the meteorology. We also completed a series of verification projects on the grids coming from GFE. Another verification projects is underway.

developed a suite of 5 graphic products with basic scripts to aid in creating them for the marine program (www.wrh.noaa.gov/pqr/ifps). These are currently non-operationally created.

WFO LUB has been using the RPP to support a graphical Hazardous Weather Outlook. We, along with WFO's Tulsa and Tampa Bay have used the RPP to develop a GFE training course to support RPP 11 deployment across the Southern Region.

The RPP is currently being used to produce two experimental products. 4-7 Cloud Cover forecast (produced once a day) and 12-48 hour Probabilistic Flash Flood Guidance (produced twice a day). We are also in the process of creating future experimental products, (e.g. 4-7 Probability of Thunderstorms and a 4-7 day Wind forecast).

We have been reviewing and evaluating the software while using it to generate operational products. Occasionally, forecasters have identified items that can be improved. We also serve as an alpha site for new releases, testing advance copies of the new releases to make sure they load alright and there are no obvious bugs that have been overlooked. The software is used operationally by the entire staff to generate graphic and tabular products for display on the WFO Boulder web page. Preliminary zone products are also generated with the GFE formatters. We have been posting graphic imagery and tabular products on the web twice a day since June 2000. Zone product generation started in mid-September and has been used regularly on the midnight and day shifts since then. The software has also been used in the development and testing of the product formatting capabilities. This includes a zone formatter, a fire weather product formatter, a CCF generator, and outputting data for the National Verification Program matrix.

GFE (RPP13) used operationally to generate grids that are fed into Awips ifps matricies and then to formatters.

The RPP GFE is used daily in operations with the Alpha IFPS software from MDL (5.1.2). Our grids are edited/saved in GFE on the RPP then transferred to our Alpha IFPS for use in IGR. We run two GFEs on the same RPP machine, one in 5km resolution for "public" products and another in 2km for our Marine products. From the public GFE, we post max/min temps for the next 2 days/nights to our web site. From the marine GFE, we are creating hourly graphics of winds and waves out to 36 hours for several near shore zones, as well as text/tabular point-specific forecasts for several port cities. Our office also actively participates in the RPP process, reporting bugs and maintaining frequent contact on the listserver. By Dec 1st, we expect to be posting graphics of 3-hourly temps, wind chills, snow amount, and weather.

In this second section, you are asked to comment on the GFE training, as well as the various on-line training manuals.

4: Briefly describe the training you received on the GFE (e.g., training at FSL in Nov '99, Mar '00, or from another source).

Most of the training I received on GFE was from Jeff Manion, and mainly when the first RPP was installed here. I received additional 'nuts and bolts' training on configuration starting in winter 00/01, and that seems to be the training that never ends! I also went to FSL in Sept 01 to see some of the new features for RPP 13.

Received training at FSL during the Apr '01 RPP Focal Point Seminar. Also attended IFPS Focal Point at the NWSTC in Sept '01. In addition, I reviewed several of the online materials that are available.

Training at each of the FSL RPP meetings, up to the present. Was also involved in developing some features or product generation techniques, which involved working with developers on a one-to-one basis. This was primarily in text product generation and smart tool development. Have also looked over the online Help document as a reference for smart tool and configuration file reference.

training at FSL in previous RPP workshops as well as office training from the SOO. Also, just daily use of GFE.

I've been to one workshop for sure, I think it was Mar '00. I don't remember for sure and I don't have the information handy. Most of my training is from reading the online documentation and asking questions via email or the listserver.

That is a difficult question...all of the training wasuseful...the workshop was well planned and of relatively short duration...all of the training was useful.

well, when first getting trained, and even now in some respect, the buttonology on the new things is always helpful. In addition, there are still things that I learn about configuration with the advent of new builds.

Demonstrations of GFE functions and capabilities have given me many ideas which I have implemented back at home. Face to face time with the developers, other focal points and SSD representatives is valuable. Developers are so familiar with the software they can give great time-saving tips either directly to me, or to other focal points, which I can pick up on. Talking with other FP's helps avoid dead-ends or pitfalls in how IFPS is implemented in an office.

I have found that the training materials associated with the actual RPP Build to be the most useful.

Learning about the BASE/SITE/USER concepts (Nov. 2000) in a lecture format helped a lot with understanding how the upgrade to RPP-7 was going to work. Lectures on smart tool coding has also been helpful.

Overview and heads-up of new software changes at Nov. 00 session. At the time... thought we would be seeing new software load incorporating BASE/SITE/USER sooner than we actually did... thus could not apply knowledge gained as soon as I would have liked.

I had some one-on-one training with Tom LeFebvre which was the most useful. The hands-on portion of the workshop were also useful.

I have found that there are no aspects of any training that I found to be not useful in some way.

7: Briefly describe the training you conducted with your staff (include time estimates).

All of the staff were encouraged to go through the RPP users manual on their own. After this familiarization, all of the staff received one on one training. The one on one training lasted from one to three days depending on the aptitude of the trainee and consisted of preparing a full set of forecast grids operationally in real time under the direction of the trainer. Care was taken not to undertake training if active, complex weather was anticipated.

Most training prior to Jan '01 was done by Jeff. After that, once we got Awips 5.0, we immediately had to do some quick training so that we could become operational without using the old ICWF (which became instantly unaccessible). To become operational, I would say each staff member received around 2 hours of training, however, we had been using it for home page graphics before getting 5.0, so it wasn't the first time they had seen this. I have also conducted an in depth training session at ABR last week, which was 16 hours or so last week. Training at EAX has also been done for Central Region IFPS focal points, I believe there has been around 10 offices here...but check with Manion for specifics. Each focal point is usually here for 2 to 3 full days. And, with all the new RPP builds, there is always some form of training that is going on with the staff.

During the Spring of this year, we introduced RPP grid editing to the WFO LUB staff. We mainly concentrated on the Weather grid to support a graphical Hazardous Weather Outlook. I am currently designing a new local training course to reintroduce and retrain on the GFE to support IFPS.

In the past medium range forecasters were briefly trained to modify automated products to better fit their forecasts. At this time, no training is being conducted.

Formal training sessions have been limited. Probably 1 or 2 one hour sessions with each forecaster in the past year. However, as product generation techniques evolved, I spent time demonstrating these to forecasters individually. Also, as forecasters came up with questions about methodology or technique, I would respond to these on an individual basis. I also sent about 12 e-mails (1-2 pages in length) to the staff explaining recent developments, bugs and work-arounds over the past year.

Our in house training was conducted mostly be our SOO. We found it best to do training in little mini-sessions of about an hour, covering different topics each time. That way it's not "information overload" all at once. I must add that really the best way to learn is simply by using the GFE over and over again.

8: Did you use the GFE Training Material (which includes GFE Spatial Editor Training Guide, GFE Grid Manager Training Guide, GFE Temporal Editor Training Guide, GFE Smart Tools Training Guide, GFE Text Products Training Guide) for onsite training?

11: Please comment on anything you would suggest changing in the GFE Training Material.

It's been a while since I've really looked it over, but I think it would be nice to have lots of step-by-step examples of how to perform common, everyday operations. (Rather than just having information there to be interpreted.)

I still think the material is poorly organized. I spend a large amount of time trying to find information. Once found, the information is invariably well written and useful. I also dislike having only an HTML version of the document. While I understand it's not cost effective to provide hard copy documentation for a rapidly evolving project, perhaps the documentation could be provided in a format designed for printing, like Postscript or Portable Document Format.

I did not have our staff go through the FSL training. This is because I developed our training in 1999 when the FSL training was pretty basic. When we finally got around to having our staff go through training (spring 2001)I just updated the job sheets I had developed and had tem do that. I think the training is much improved for the forecaster and FP. My training was very task specific to get the products I wanted them to produce. They now need a more generalized training program to become better overall GFE users. I will use the FSL training much more in the next round. I am not familiar enough with it to critique the current version.

The training material is quite thorough and very useful as a reference. However, it is probably most useful for the focal point at each office. A lot of the material is more than the rest of the staff needs to know. The Spatial Editor, Grid Manager and Temporal Editor Training guides can serve as good reference materials for the general GFE user, but the Smart Tools and Text Products Training guides are primarily of interest only to the focal point. The configuration guides are also of interest to the focal point only. I say the training guides are a good reference tool, but only after the GFE has been demonstrated and taught to new users in a one-on-one training session. A brand new GFE user would probably be overwhelmed by the learning process if they were just given the training guides and told to learn how to use the system. A personal demonstration goes a long ways toward showing how the system can and should be used. I don't know that I would change anything. Just understand that a lot of the stuff will never be read by the general GFE user.

12: Would you endorse the Train-the-Trainer concept as a prototype of GFE training to be conducted throughout the NWS?

It can work. But the Trainer would need to receive a fair amount of training in GFE methodologies and techniques before being expected to go back to the staff and train the rest. Now that methodologies have been developed by early users of GFE, the training of the prospective trainers can probably be accomplished in the space of two weeks. I wouldn't want to go much less than that. The concept of Train-the-Trainer should be able to work. However, it will work best when all the concepts and software have been fully developed. Up to this point, the Train-the-Trainer concept has been forced on users with software that is still developing and with methodologies that are still being defined. These "moving targets" have acted to make Train-the-Trainer less than successful. We are now seeing people trying to learn software updates and new configurations with essentially no training. This has probably been frustrating to those who have been trying to be the trainers.

While I way yes, the answer to this question is not simple. GFE is very powerful and has many features to be learned...in addition to an overall philosophy/strategy as to when and how to use the features. In an ideal world, I would like to see training conducted as it was for the 88D... a 2 - 3 week residence course. However, given the financial/resource constraints under which we operate, the train the trainer concept is workable albeit less consistent.

If there is someone who knows all the intricate things with the new builds, it would save time for them to explain to the focal points. Rather than having the focal points learn it all from scratch. Sometimes it is hard keeping up with all the great changes! That was one of the reasons I was out at FSL this fall.

I think it works. T the T has its critics but so much of training effectiveness depends on the motivation of the trainee.

I find training the staff to be one of the more challenging aspects of GFE. Perhaps some sort of computer-based training module could be developed to at least give a thorough introduction to the "knobology"

I have never supported the Train the Trainer concept. We are trained as meteorologists and most do not have a background in teaching. The NWS should seriously consider designing a residence course for the GFE and the remainder of IFPS for ALL forecasters. This is especially true since this is a major shift in forecaster methodology.

With Train-the-Trainer... having to work around scheduling conflicts... typical office interruptions and possibly weather. In my worse case... I was providing instruction to a forecaster... but had to break it off in the middle of the training to deal with a developing significant tornado outbreak. Due to damage surveys and scheduling conflicts... it was several days before we could resume GFE training. Unfortunately... costs probably prohibit off-site training for all the forecasters.

IFPS presents a very steep learning curve. I feel that ALL operational NWS meteorologists should attend at least a two week residence training course on GFE/IFPS, similar to the old 88D course. Obviously that's expensive, but it is just as important as knowing how to use the radar.

Train-the-trainer is the least effective way to provide training. If there were dedicated training staff in the forecast offices, train-the-trainer might be adequate, but there aren't dedicated training staff.

14: Please list any other comments about the GFE training you and your have staff received.

The training that comes from FSL has been very helpful....as much of it comes via email. And it comes in a very timely manner. I would also consider the GFE online help a form of training, which is miles above any help that comes with the IFPS software. In addition, I still get help on things from Manion at CRH.

Our forecasters are basic users but don't use the GFE to it's real capability. We are going to hit the staff with another round of training as we begin to generate less specialized routine word products with IFPS. We will probably make use of te FSL on-line training much more this round. For myself, I have been using GFE since around summer 1998 in Boise, so there is years of familiarity as well as some more rigorous training in my experience.

When it has come to methodologies, it has been a lot more discovery and development than training. But I wouldn't exchange the opportunity to be in this position for any other options.

It's important to revisit training after a while-- not just do it once and be done with it. It's an ongoing process. That way, after forecasters gain more experience on their own time, they stand to get more out of a session with a trainer. (they'll have more questions/comments.)

During this year (2001), software releases RPP7 through RPP13 have been made available to the RPP sites. In the following questions, please comment on the software update process. Refer to GFESuite RPP Progress and Management Teleconference Reports.

We have updated every single change *except RPP 12* since January '01. This was not done to restrictions from the NDFD.

Tried it once using netscape on our RPP machine. The file was too large and netscape was estimating hours of download time. It finally timed out with maybe 30% downloaded. I'm sure there is some way to use the WAN, or something to maximize throughput, but I just wait for the CD's and spend my time on other GFE things.

more difficult as opposed to CDs, in that at least for us, it adds several steps involving a couple different machines

Installing the software from the GFE web page is difficult because it involves having to move the software through the AWIPS firewall. In my case, that involves getting the SOO to do this.

The only one we've done from the webpage was RPP 14 due to mailroom problems at FSL. We also downloaded a patch for RPP 11 off of the webpage.

I hadn't used the webpage much because our office had had a horribly slow internet connection. This was upgraded over the summer. I have downloaded the software using my internet access at home, which is better than what I have at work.

This has been very easy to do. My only problem is storing the growing collection of old and useless CDs from previous releases.

Since our office runs operationally off the RPP GFE, I generally wait 2 weeks or so after I get the software and see what type of bugs are reported on the listserver. If they don't sound very critical I go ahead and load it.

VERY EASY. I would compare this to a novel called 'RPP installation for dummies'. when i first started doing the upgrades, I knew little to nothing of the process, but i am a master at it now...and it happened right after the first one! (let's not talk about upgrades to IFPS, which just hammered our whole system last week)

The process is so easy, that in most instances I've been able to install a new version of the software and not even let the forecasters know that anything has changed. After an install, I verify that graphic generation and text product generation programs work, then I can come back the next time to begin learning about new features contained in the new release.

I have no complaints the last year. My local configs are preserved, etc. When we FSL first started the base/site/user thing I had to manually create each tool and procedure within GFE to get everything kosher with the server, etc. Now I have everything cleaned up. I found it useful this summer to look through the log files. I found some .py files that did not have info files. Lots of error messages were being written to the log files when you did things like start the "make products" interface. Now I seem to have everything cleaned up and it runs smoothly and upgrades have been very smooth. I would recommend telling all focal points to look for these type of errors in the logs. I think writing to the logs slows the software down (especially on a dog PC like mine!)

It is a little harder doing it from the webpage, just due to getting it through the firewall, and untarring/zipping the files in the appropriate directory. There really isn't anything hard about doing it from the CD.

Losing any databases (official and model) could be a pain if an office is totally using IFPS in routine operations. This manageable for us since our stuff is less routine and more "specialty" products.

The time needed for the ifpServer to generate all the necessary files after a new install is quite lengthy.

ensuring that you have absolutely no files anywhere that could get overwritten by the new release, and making sure you back-up the existing/current grids so you can have them for the forecaster on shift after the install. Also the threat that things may not work exactly as "normal" when you come back up.

Every software release has been very easy to install. Typically the installation process takes less than 10 minutes with very few, if any, problems.

The install process itself is simple, I think mostly because all the prompts at the start already know your configuration (what site you are, RPC port, etc.), and you can just hit enter all the way through.

24: Rate the usefulness of the Upgrade Instructions and Release Notes that accompany the GFE software updates.

I think they've gotten better. Early versions for NDFD machines still had references to RPP configuration which caused some confusion.

Some errors took a few build to get corrected. The install notes referred to default resolution as being 10 km when the document also stated that default res. had been changed to 5. I have noticed a few little things like that.

The only thing I can compare it to, is the release notes we just got from MDL for the awips 5.1.2 upgrade. We are STILL trying to recover from problems due to lack of detail on their notes.

They typically contain critical information for the new upgrade. Wouldn't do it without them.

I even had our ESA use the upgrade instructions to change the NFS mounts on our Linux boxes.

The upgrade instructions and release notes are always very well written and thought out.

Send out an e-mail to let them know if something is not working, it could be related to the upgrade. I also try to mention a new feature that may be of interest to them.

30: How frequently did software updates reflect changes recommended by you or your site? Refer to the Release Notes GFESuite RPP Progress and Management Teleconference Reports.

31: To the best of your knowledge, list the changes that did make it into the software.

I am not sure of things prior to Jan '01, see Manion for these details. Otherwise, I know that the progress bar at the bottom right hand corner came from us. I'm drawing a blank otherwise.

The technical documentation is MUCH improved, which I had complained about. Andy E. and I recommended the flow from left to right of the GFE top button bar (mimicking the forecast development and dissemination process - configuration, populating, manipulating, publish) etc. This came up at a brain-storming session at FSL maybe 2 years ago. I don't know if these were original ideas of ours, or if FSL already had the idea in the works but it has made it into the software (and I'm proud of it whether it was my idea, or not!!). Compare the GFE tool bar flow to the TAF edit tool on AWIPS. The TAF edit tool bar flows backwards from right too left when you go to write TAF's. This seems completely backward to me in a world of GUI's. FSL has been very open to suggestions from any level of experience and whether a person is a general forecaster or a SSD director.

don't know of any specifically, but this due mainly to our in-activity with suggesting changes lately.

Access to Edit Areas through a pulldown menu. Some changes to the "Load Sample Set" GUI. Changes to the "Publish to Official" GUI. Moving some Edit Action capabilities to the color bar and spatial editor. Making the number of QuickSet buttons configurable. Adding some functionalities to the color bar. Various PNG image generation things. A lot of text product generation capabilities.

We've been so far behind on software builds (until recently) that I quit making suggestions since odds were good that the suggestions had already been addressed.

image smoothing is one I can think of. kind of a broad question though. There are some really minor things and also a few items that are hard to describe in short answer format.

I wasn't very active this year. However, recommendations I made to create OCONUS defaults in the BASE configuration files were implemented.

32: To the best of your knowledge, list any changes that did not make it into the software.

The GFE/RPP feedback process allows focal point to provide feedback to developers using different mechanisms. The following questions ask your thoughts about these mechanisms:

The call this past week was the first one that I've been on shift for. Manion most always participates in these.

I haven't been available for any of the calls in recent memory...the SOO has taken part in a couple.

I don't see these as the best method of really giving feedback on technical things to the developers.

I believe the method in which each office checks in is very disorganized and often takes too much time. I'd suggest role call procedure where each office is called individually.

35: Rate the usefulness of the Monthly Conference Calls for discussing progress, upcoming events, site status, and development status.

37: Rate how often you made Direct Calls and e-mails to FSL (i.e. response to questions, problems, etc.).

Since RPP 13 and ISC stuff, I've talked to Mike Romberg and Mark Mathewson directly with issues.

depending on the problem or situation, you could have frequent contact during a week, then not communicate again for a month or so.

Ease of access makes this response non-representative. When I'm on day shifts, I talk to the developers on an almost daily basis.

Any time I had a problem the developer responded quickly and the problem was resolved in short order.

can there be any more said about 'very useful'? These are fixes that can be made IMMEDIATELY, vs waiting to go through NCF and THEN to MDL, which at times can be a matter of weeks.

Very very useful. I try to limit direct e-mails. I know my problems are small in the big picture and the only way to learn something like python is to dive into it and not ask for help at every turn. But, when I do e-mail the response is very helpful and very quick.

I almost always get exactly the help I need and it typically solves the problem right away.

I see all the e-mails that are posted on the listserver, but haven't actually gone directly to the listserver. If a topic is currently being discussed, I'll hang on to the messages in my e-mails to see the resolution of the problem or discussion point.

I haven't posted anything to the listserver in a while. I read the daily summary of the activity on the listserver every day I work.

I read the listserver every day and most days there is info that I find useful. I infrequently post to the listserver, only when I run into a problem that I have been unable to resolve otherwise.

I do not believe the list server should be use to support non-RPP sites. Maybe FSL should consider having an additional listserver to support non-RPP sites that are using the GFE operationally (including Southern Region).

While I don't post messages this often, I read every message that appears. I have gotten a lot of useful information from this listserver

The listserver is helpful for not only posting and receiving responses to my questions and concerns, but by reading the questions and feedback from other offices I am able to avoid potential problems ahead of time, as well as receive useful pointers and suggestions.

I respond to some discussions but learn from many more. Some subjects don't interest me, like populating from MOS (it doesn't work for us - too mountainous). I also keep an eye on the national IFPS info list.

the listserver has almost always been able to supply help or at least insight into my problems.

Numerous problems have been solved by the exchange of information that the listserver facilitates. Sometimes, though, it is difficult to convey all the information I want to across the list. For example, you see somebody struggling with something, then try to help by posting something, then don't know if the original problem has been solved or if the new technique or concept has been effectively conveyed to others on the list.

The listserver is by far the best resource for getting a solution to a problem. Sometimes just searching for messages about a problem that may have already been dealt will be sufficient rather than posting a new question.

45: How do you collect feedback from your staff on various GFE components and new features?

Not very often; however, anticipate this will dramatically change once our office implements the GFE in a full forecasting capacity.

Guys will leave me notes, or e-mails about problems. Also through one-on-one discussions when we are on shift.

This section asks you to comment on GFE Documentation and additional Support Information.

I use it mainly to prepare for upcoming meetings and to implement new smart tools. I don't use it to download software but sometimes do to preview release notes before I get the CD.

FSL should be commended with their efforts to keep the documentation current with each software build released.

The only recommendation would be a search engine. Otherwise it is the best thing out there for info.

50: Rate the usefulness of the GFE User Manuals (which includes the Configuration Manuals, and Users Manuals for ifpInit, ifpIMAGE, ifpNetCDF Formatter, ifpAG, etc. )

There is a lot of documentation available. Sometimes it takes a couple tries through the links to find the item of information that I'm after.

As with the training documentation, I think the other documentation is poorly organized and I would like to have hard copy documentation provided or have the documentation provided in file formats designed for printing.

It is amazing how good things seem, when compared to things that are NOT so good. I'm referring to previous comments about other documentation...

I reference them a lot. There are still some little things which are frustrating. We in the field take the examples and implement them exactly as presented and some have some bugs or typos. I have gotten much more familiar with navigating through the documentation and now find it very useful. I still would like a search engine. That's a good answer for the questions above "..what has not been implemented??"

I sometimes find myself getting a little lost wandering around looking for particular answers to my problems.

I have used these manuals very heavily in developing both the Southern Region GFE course and my local course here at the WFO Level.

The web documentation is great along with the documentation available through the help menus on the GFE. BUT I will always like good old fashioned hard copies.

53: On average, how much of your time (hours per month) do you devote to RPP and GFE Focal Point activities.

Ramping the office up from ground zero to full time operational use of GFE in less than one year has taken a good chunk of my time....probably 50%. Once we get past this winter, and we get our graphical product suite settled, much less time will be required.

50 hours per month. Even on operational shifts, I find a couple hours to lookover GFE things and try to do some development. Throw in a couple supernumerary shifts which include 4-6 hours of development, and I guess I can justify the number listed above.

16. We were horribly undermanned during the last year and most focal point duties in the office, including RPP, received very little attention.

54: Please estimate the percentage of time you spend on each of the following three Focal Point activities. Your total should equal 100%.

57: Please make any comments about the time spent on GFE/RPP Focal Point activities.

We haven't had a whole lot of problems, and the staff has been trained enough for operational use for quite sometime.

With the implementation of IFPS during the next 8 months at LUB, I have found very little time to spend on the latest RPP Build. This has hampered my ability to give active feedback to FSL. I anticipate this will continue through at least RPP 14 and possibly RPP 15.

The time spent can be quite rewarding when you get done with a new capability or configuration that allows the project to take a step forward.

One of the goals of the Rapid Prototype Project was to "speed up implementation of the end state Interactive Forecast Preparation System." The following questions ask you to rate the "progress" to fulfill this goal, and how close to an "end state"(to date) you consider the following areas:

There still are some important components to implement like mature ISC and verification, grid comparison, etc. I think the framework and foundation are solid.

I think the real work still to be done is in coming up with smart tools to bring data fields into a realistic looking state in complex terrain.

We went from ground zero to full time operational use in less than one year. I think that is a significant accomplishment.

The staff has moved to the point of regularly using the software to support operations. You can't say the UI is completely mature, but if nothing changed, the system is still good enough to be used all the time. The overall UI has undergone little change in the last year which may bean indication that new improvements are going to be more difficult to accomplish. Screen space seems to be turning into the main limitation of the UI.

61: Progress

These things have undergone less change than other UI issues which may mean that these are mature.

We have not yet learned to fully take advantage of the power of the tools provided with GFE. This will take a little more time and experience and perhaps more training.

Smart Tools and Procedures. (Please consider the capabilities provided in the GFESuite for you to write your own Smart Tools and Procedures locally.)

For some reason, before numeric python was 'discovered', we basically could not run smart tools, due to the time it took for them to run.

The infrastructure for writing smart tools now appears to be nearly in place. The next step is going to be having someone validate the tools that are being created. There is a lot of potential power in these tools, but it is also going to open a Pandora's box of tools that may be meteorologically incorrect or improperly apply the utility of the tool. People are already clamoring for this panacea of smart tools, but the repository has not been able to meet that need yet.

68: What percentage of the Smart Tools have you converted (or originally written) using Numerical Python?

69: Have you modified the Smart Initialization algorithms?

We will be doing a lot more in the area of smart tools and smart init in the near future as we rededicate resources from other activities and from learning to use GFE to making the use of GFE more efficient.

actually less than 10. I've started to play with a slcMRF.pyfile. I want to explore this much more in the next few months. This is really interesting stuff for me. If initialization is the best it can be, everything else will flow more easily.

Trying to get the Haines Index to work right. Different Temperature algorithms, depending on model being initialized.

72: Would it be helpful to have a Smart Tools 'Czar' located at FSL to assist you in writing tools on your behalf and to answer questions related to Smart Tools, Procedures, and Smart Initialization?

This would be of great help to the field and I can't stresshow important it would be to do this. Kind of like the SOOSAC coordinator when the SAC was introduced to the field.

So far, I have not had a lot of time since the RPP 13 install to get our tools switched over to numeric.

It's exactly what we need. This czar could certify that a tool is valid for use in GFE, and keep track of what already exists and what is being developed. If one person were in charge of the process, we could move towards standardization across the NWS.

Very little vision has been offered in this part of the project. It seems that most sites are still trying to setup the software and train staff. Without vision and boundaries, RPP sites have little motivation to try something new. On the other hand, posting graphics is something that is never been done before, and using the text generating utilities are a new methodology that falls under modernized ways to create end products.

It seems that in the products end of GFE...everything was left up to the offices...well not everything...the infrastructure and documentation were provided but it was left up to the field to put together the pieces. That's OK...but in my opinion it would be better to give the field a set of baseline products they can use out of the box and let them customize and add to the suite...and this included graphics, tabular, and text. Also, guidance/support from national and regional HQ's(particularly national HQ) regarding has been less than optimal. I am disappointed that national HQ hasn't taken a more active role with respect to modernized products. On the other hand I suppose it could be argued that it is better that they have not gotten too involved.

Forecast Process Definition using the GFE (e.g. Initialization -> Data Review -> Grid Editing -> Publishing -> Product Generation)

While I don't have a lot of experience, unfortunately, using the GFESuite I am concerned that the grid editing process will not result in more time for the forecaster to have for meteorological reasoning. I think the grid editing process may well replace typing as the overhead of a shift.

Since so few sites are using the software operationally in an end-to-end process, we have to say that we are near the beginning of this process. But I guess the answer to this has to be given relative to the context that GFE is being used in. If the context is use of GFE within the rest of IFPS, then some of the sites have shown the process works, and the answer may be we are near Mature Operational State. If the context is using GFE exclusively to produce products, then I will stand by the Early Evaluation State. But the fact that this office has arrived at this point is a significant accomplishment, that I'm not sure anybody was looking for.

The RPP process should be a model for NWS software development and integration into operations. It works and it works very, very well. Also, kudos to FSL for a job well done and an outstanding level of support and response to RPP sites.

I would say that the RPP process is needed to keep the 'NWS Vision' up to speed. If we had to wait for new awips loads to come out, instead of the quick RPP fixes, I think that there would be some kind of office mutiny, and I would be too dead to write this! I also think that the RPP speed of changes keeps the creative juices flowing...without which, staleness would occur...just waiting for new things to get here. I know that the staff here appreciates that the changes we come up with can be quickly put into effect, showing that their opinion counts for something. I don't think I can comment the RPP Process any more than I already have!!

I'm excited about the future of IFPS because of the great progress we have made in the last few years.

I must again take an opportunity to compliment FSL on all aspects of their support. Many times we receive answers to questions over the weekend. Mark and his team often times go above and beyond what I consider to be the expected standard support. Their feedback is always immediate and I believe this is one reason the RPP has been so successful.

I'm glad I've been able to participate in the project, but I wish there was a little more recognition of all the potential capabilities that exist in GFE from regional and national headquarters levels. We've shown that you can produce the current suite of NWS public products from GFE, completely independent of IFPS, yet there is little recognition of this fact from policy makers. Rather, the RPP has recently seen efforts to shut the project down. This should not be tolerated.

The interaction with the IGR software in IFPS is, in my opinion, really slowing the end-state IFPS implementation (at least in our office). We are transferring grids back and forth to satisfy both GFE and IGR, when you really only need the grids in GFE for everything. Ideally, all the work that MDL has done with the formatters in IGR should be merged with GFE so the forecaster can work in strictly one environment and not have to duplicate efforts. Forecasters like "one-stop"shopping and should not have to wait through multiple grid transfers when creating a forecast.