The purpose of this survey is to systematically collect feedback on the training you received on the GFESuite and its components during the RPP Focal Point Workshop, November 14-16, 2001 at the Forecast Systems Laboratory in Boulder, Colorado. 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 training and system development. Feedback from this survey will be compiled by the FSL Evaluation Team.

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.

This was an excellent workshop. It is always nice to learn from the people who create the software; however, I understand the time constraints.

I have been a user of several different versions of GFE, and used precursors to GFE in the mid 90s. I have just recently (past 6 months) gotten into configuration and maintenance of the databases associated with GFE.

GFE is very robust, but also complicated at times with so many features. It would be nice to have all forecasters train on GFE at a remote course similar to the WSR 88d training.

I have done basic configuration with localConfig and Maps and ifpImage. Not many smart tools yet.

No formal training, just 3 days of hands on training at RLX. Everything else has been self learning

Attended all RPP workshops. Also evaluated GFE versions from 1998-2000 via the IFWG.

Have attended each of the previous RPP workshops. Have worked with developers from time to time, developing and implementing new features. Have referred to online documentation as necessary to learn techniques in developing smart tools, text products and imagery.

2 days hands on time at RLX. Self study and practice in house since July. Info from online documentation and listservers.

Working at Tulsa WFO 1995-1998 3-day training at WFO-Charleston, WV Nov 19992-week IFPS Focal Point Course in Kansas City, March 2001

Local on-site training from the Science Officer and IFPS Focal Point. Self-taught GFESuite features from internet documentation (including Smart Tools and some config information).

On site training in operational use of GFE given by the SOO and Steve Nelson. I've spent several days reviewing all the training material on the web.

On-line training using the RPP websites. Attended the Apr and Nov 2001 RPP Focal Point Courses and received hands-on training on both occasions.

My formal training consists of the NWSTC pilot IFPS course. However, I have been out to FSL twice, and get quite a bit of training through Jeff Manion (crh).

Not including the latest GFE course on GFE14, I got a 3 day training on IFPS, the short course and 3 days at RLX.

Zero formal training prior to the RPP workshop. Participated in the IFPS Focal Point Training at the end of March '01

RPP Workshop - 11/2000 NWSTC AWIPS IFPS Course - 12/2000 RPP 14 Online Documentation

5: Briefly describe (if any) training you have conducted with your staff (include time estimates).

Between 400 and 500 hours of one on one training for staff. This was divided up into 3 phases. I sat with each forecaster for 2 full shifts and we did the actual forecast for the day. Phase 1 consisted of POPs only and learning all the buttons. Phase 2 consisted of doing Max/Min T and Td. Then phase 3 finished off all the grids. This was done over a 4 month period

Our in house training was conducted mostly by 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.

Trained Tulsa WFO forecasters 1999-2001, approximately 3 rounds for each forecaster with 2-6 hours sessions for each.

GFE training for three to five members of staff, one-on-one or two-on-one, with demos; compilation of training materials in binder near workstations; forecast methodology for winter weather to staff at seminar (10-15 hours)

about 2 hours each in job sheets I developed for GFE at SLC. Some one on one training, also.

GFE procedures /policies binder and e-mail. Personal 1 on 1 training (about 3-4 hrs per person).

We have taught the staff to load the Meso-Eta data (30 minutes/person). Formal GFESuite training begins in JAN 2002.

Have trained the entire staff at WFO. Training has included two or three 2-4 hour one-on-one sessions. I've also composed numerous e-mails explaining new GFE features as well as techniques for producing graphic and text products.

Prior to course, we spent about three half days working with each staff one on one. Just finished a refresher presentation for all staff to review which included an brief exercise. Estimated time per staff member was 90minutes total.

Staff training approximately 100 hours total; southern region GFE course training about 100 hours

One-On-One (15 h)Small Group (15 h)Methodology/Job Sheet development (6 h)Staff Meetings (3 h)Meteorologist Meetings (12 h)

3 different group training sessions (each held 2 times to maximize attendance) 1-2 hours each.2 one-on-one sessions with each forecaster - 1 hour each - total 10-12 hours.

Nothing brief about local training! It is time consuming. We are now in our 3rd wave of training, consisting of creating Job Sheets for tasks, one-on-one training for a couple of days per forecaster, email Q & A, Proficiency Drills... I spend about 15-20 hours per week writing the sheets/drills, sitting down one on one with staff, and answering/finding answers to emails through various internet outlets. This is in addition to time spend customizing the software.

2 Hours Joint Training, Knoboloby2 Hour one-on-one training, mostly Knoboloby some methodology daily grid editing since October by forecaster on duty, approximately 1 hour per day.

I have conducted limited training with our medium range forecasters regarding preparation and dissemination of our experimental medium range products.

Own staff: Three day seminars (6 hrs apiece) 3 one-on-one sessions (4 hrs apiece)On shift training/assistance as needed. MRX: Two full days - 14 hrs total. Other eastern region offices visited to receive operationally training - about 2 days apiece.

Nothing formal; will be more active in training with the newer RPP features once it is set up. Still waiting ER approval.

I have conducted, with the help of one other person, one on one training, about 2 hours in length, with each staff member.

When we first went operational with the GFE, we had 2 hour long sessions with each forecaster. It didn't take much more than that, since we had been doing RPP products for about a year. Since then each new forecaster to the office gets about that much time. In addition, whenever I put on new 'options' or tools, I always do some type of dog and pony with each fcstr.

On GFE only, the SOO and myself trained the staff on GFE. Each forecaster got 4 hours training. We also required all on station to go through the prelim training as prescribed by ERH. This was an initial training session on the Scalar fields. The vector and weather fields will be treated in future training.

Seminar conducted in May on IFPS/GFE/NDFD (presentation is on our Intranet). Spent a minimum of 2-4 hours with each forecaster on GFE training. The latest RPP user guide is made available and forecaster help sheets have been prepared. Will conduct another seminar Monday Dec. 17 to review RPP14 and what to expect in RPP15, ISC, and NDFD Cluster meeting notes.

Just starting full training this week. Preliminary training involves bringing up GFE, and populating the database with MesoEta then stepping through the grids to examine model output.

2 hour presentation to 3 groups on basics of the GFE. Developed ongoing web based training (Job sheets) based on training modules in online documentation. One on One as needed. It usually is.

Introductory presentation to staff during staff meeting (30 minutes)Group training sessions on GFE Introduction (1 hour) One-on-one training session with each forecaster (4 hours)Forecast training shift with each forecaster (4 hours) Individual consultation as needed.

All staffed trained on GFE. Total time is 16 people X 6 hours each or 96 hours. This was initial training. More to come.

At CRH, very little at EAX, 100 hours? training CR IFPS FPs during IFPS familiarization visits, 80 hours?

6: Rate the usefulness of the each of the Joint Morning Session presentations listed below:

Good to see background progress, nice and brief too so that more time could be spent with the system itself.

It was nice to see how far the software has come, especially when you look back at the old AFPS stuff.

Interesting, but not of real importance to existing software; except RPP/AWIPS software release relationship, FSL role and Future Plans were valuable.

There were some useful aspects. But by the end, it started to be a too-big-of-sounding board for some people that needed to share.

I did not have any previous GFE except from Awips 5.0 and 5.1.1. However, the new features will be very useful indeed. I especially like the new IFPimage portion and the Smart Initialization.

I have not seen what improvements are headed our way. We are still using awips 5.1.1 RPP 10 and the new features are leaps and bounds ahead of what we are using, and are exactly what our forecasters are asking for!

Covered some features I am already experimenting with, and others that I am anxious to try.

With no experience with current RPP build, it was good to know the differences to be looking for.

I already knew about most of the stuff, so it didn't mean that much to me personally. I'm sure others found this more useful than I did.

While the presentation was short, it sparked an interesting dialog with the entire group. I think it is important that the group discuss this. That way individuals and offices can qualitatively synthesize the various methodologies and not try to get "funneled" into one or two specific methodologies.

This aspect of forecasting grids is very important and should be expanded on in overall GFE/IFPS training.

Enjoyed seeing what another office had done. The prospect of Fire weather being generated directly out of GFE is exciting. Really emphasized how important and time-saving smart tools can be.

Eye-opening seeing how offices are using GFE suite to make it a stand-alone forecast tool. As someone new to RPP, I had no idea.

It was helpful to see approaches used by other offices. It was especially enlightening to see what other offices have been able to accomplish. As an operational forecaster at a 2-forecaster short staffed office...their results were incredible.

always interested to see what approaches other offices are taking... and possibly incorporate some of their ideas into our scheme.

It was good to see the stuff that Charlie Paxton presented. It is starting to look like Methodology is going to become its own "creature" that will need some management, so it doesn't get out of hand.

It was good to see that other offices were approaching the fcst the same way as we do in RNK.

Most forecasters will need to develop their own methodology based on site-ready procedures and smart tools. The main point each site must consider is how to proceed with tool development (ie. POP to WX, or WX to POP, or both ways).

Interesting, but believe that this single topic could (should) support another workshop by itself. How do you efficiently do a complete forecast (with coordination) within the allotted time??? Is one order of editing grids any better than another? What smart tools are available? Would have been nice if everyone brought a list of tools/procedures to share. GFE allows multiple ways of doing things (good) but is one way more efficient than another?

A little interesting on what a couple of offices have done so far, but I did not come away with much useful info.

Because I come from national center, the suite of products we produce and the methodology we approach them with are different than those seen in a local forecast office.

Most offices will figure out on their own what the best strategy is to accomplish the mission.

13: The Two-Track Schedule was designed in order to accommodate the large number of attendees. Please rate the effectiveness of the Two-Track training strategy.

There was lively discussion with the smaller groups, that was actually helpful. And it was easier to ask questions. And get some individualized help.

It was obviously a good way to deal with the surplus of attendees. Making the two tracks slightly different was nice. A choice!

It seemed more confusing for the instructors than the participants! It was nice to be able to have that many people at one time as we were able to exchange ideas.

I guess the only thing was that it appeared Track A had the more advanced users and I missed out on any of their comments.

Good way to deal with large number of attendees, although smaller is always better. Felt a little rushed at times.

Necessary to ensure equal time on the machines for each participant. Would have been nice to have more machines, but not practical for the number of attendees.

If we get a group this large again, it may help to even have at third track, especially for labs, so each person could have their own workstation. I'm sure this would be logistically challenging.

It was much better than the last complete RPP conference. I was very well thought out and the preparations were excellent.

It would have been nice to have a bit more time for interaction between the two tracks. I understand that there was a lot of stuff for both tracks to cover, so the strict scheduling was necessary. The fact that very little free time was available is a testament to how bad training like this is needed. The workshop needed either more time, to allow attendees to digest the information, or less things needed to be covered. However, everything that was covered, needed to be covered. I don't know what could have been left out.

It would have been nice to have a little more group time with everyone attending. Not just an hour at the beginning and the end.

With such a range of expertise, I suppose the two-track is the way to go to maximize the learning by all.

I had no problems with classes, but it made meeting with other students for discussions harder.

You did a good job with keeping two training sessions going simultaneously while having to use the same resources for both sessions.

Obviously it was necessary for the logistics of the lab. However dual tracks make it more difficult to interact with people in the other group. I find as I learn just as much outside of the organized sessions through interaction during breaks, etc.

Instructors seemed to be spread a little too thin at times and/or distracted, rushing from one track to the other.

The training would have been more effective if the lectures were in the morning and labs in the afternoon instead all lectures for the first day.

The large number of attendees and the two track idea resulted in a lot of shuffling around between labs and rooms. The training would have been much more effective in a smaller group. I disliked having to pick up all my stuff and relocate every few hours. The lab would have worked better in a smaller group. I was stuck in [someone's] office while most of the group was in the main lab.

Daily Forecast Critique

Interesting to see the different directions that HQ is interested in going with respect to verification. And Tom was very receptive to ideas/suggestions for the software.

It was good to see Tom's initial developments, and it was good to give him some ideas of what direction to head in the future.

Critically important session. Think that it was vitally important that FSL got broad user input for the coord tools.

Overview of a very preliminary program. Probably as useful for instructor, getting input from the class.

I think it's a good idea, but wouldn't want to see it out operationally until the forecasters become more comfortable with GFE. They may go running for the hills and never come back.

This will be needed in the field (verification) in order to see how well we are doing, especially in complex terrain areas.

I especially liked the easy-to-follow demo; good for techno-challenged people such as myself.

I already knew this section pretty well, so probably wasn't as useful to me as to some others. But definitely a necessary review.

Presentation was suited for those who were already familiar with the program (it seemed to me); that is OK, but as a newcomer, served as motivation to consult documentation (to get up to speed).

Didn't do any lab with this... which probably doesn't matter much... since we work out the details when generating graphics at the WFO.

Some of the questions I had I did not really get answered. But we went so quickly that I felt I did not want to bog things down. But based on the material I have since figured things out...sort of.

I've already got my web image methodology in place, so I didn't learn a lot from this session. But there were a few things that were nice to learn, like setting up a configuration file of common settings that is then accessed by the specific image config files.

This seemed too basic a topic considering ifpIMAGE has been in GFE for over a year. The new features of ifpIMAGE were covered in two other lectures. A discussion of possible enhancements should have been the primary focus.

Has enormous potential! The next release will make this all the more useful. It will definitely take some getting used to, but it was good to get a preliminary feel for it now. All of the instructors were very helpful and receptive to suggestions for further enhancements to the software.

Very informative look at huge problems associated with ISC/NDFD. Lab was effective way to illustrate them.

The lecture sparked very good discussion on how's and why's and possible enhancements. The labs were pretty fun too, especially the max temp distribution at MPX! :)

This will be very critical to the field and fear it may take up more time than its original purpose.

It was neat to see the ISC stuff in action. We also identified a few things that people thought should be changed. The discussion that followed the lab also had very good discussion, which I'm sure the developers gained a lot from.

Since we had started working with this version of RPP directly after the workshop, it was especially helpful.

Can be complicated for the forecasters. Especially if we make our grids line up with surrounding offices and then they change their forecast. Also, who is to decide who will line up with the surrounding office?

Do not feel the lab was effective. It is impossible to simulate the actual forecast process in such a short period of time. The lecture was very good, and again I believe it is critically important to get field input on how the software should work.

I prefer longer and more detailed lectures and watching someone demo it rather than trying to do it with a incompatible lab partner.

Very interesting. We won't be using it for a while at SLC since no WFO's around us used GFE that I know of.

Our site (Topeka) has been using ISC for awhile, so the lab wasn't very useful. Other sites probably picked up information. However, I did appreciate the discussion time and the suggestions that will be incorporated as improvements in future releases. Still believe that most coordination will take place by phone with ISC grids an after-thought or a way to check earlier coordination.

The lecture was good. The lab was good and bad. It was useful to see the software in operation, but much of the time was wasted with participants goofing off and not taking the exercise seriously. I doubt the lab exercise provided much preparation for the problems we are about to face in daily operations, but it was a nice demonstration and provided the impetus for suggesting many changes and possible improvements to the ISC capability in GFESuite.

Useful in pointing out features, and potential problems in creating seamless national forecast

I can for see many problems down the road as forecasters begin to deal with the time constraints, stresses, and intersite disagreement while using this feature.

Is this where we used the prototype for GFE15? The combo fcst grids and ISC was nice to use.

Have strong feelings about the cost-to-benefit ratio of this wrt FSL's development time and resources as well as the usefulness for WFO forecasters. It is putting the cart well before the horse. We are still far from making scientifically sound and efficient edits to the grids but yet we are jumping through all sorts of hoops to make sure graphics of the grids look pretty across CWFA boundaries.

21: Numerical Python

Very critical. Smart Tools in complex terrain will be highly needed, as the models really don't capture the sensible weather that well. The biggest model weakness is QPF. For example, orographically driven snowfall. There is a PC version of an orographic snow model, which hopefully can be transferred into numerical python.

A presentation on the syntax of a new programming language is always useful. It was good to have the explanation of how the calculations in numeric python works.

It seemed a little like Greek early on, but some of the major differences Mike pointed out have helped in understanding numeric now that I've started to do some scripting.

Had just started working on numeric python tools, and found this to be very useful. Wish that it could have been longer, but given all the ground to cover, was probably a good compromise.

I had a basic understanding of Python, but didn't understand some of the numeric lingo. This provide a basis for information discussed later in the Smart Tools lecture/labs.

Good to get intro and reasons to look into it further back on station. Smart tools and smart init are the heart of the suite.

A necessary evil. A little too much into the theory and not enough info on the direct application to smart tools and smart init. Possibly should have been combined into a 'Smart Tools using Numeric Python' session instead?

Nice introduction to the language. Corresponding notes provided web sites for additional documentation.

I'm not a born programmer, so this part of it was harder for me. I could have stood some more time for this section, although it is the kind of thing you just have to dive into to learn. I had been out in September and did some training on this then, and Tracy had done something that was helpful...she sort of set up the numerical vs regular python in an equation format. It was easier for me to see where the "else if" statement was supposed to go in numeric. I don't know if she even remembers doing that, but it would be neat to see that in some of the "write up."

This was where I think I benefitted the most. But that is because I still have little experience with smart tools.

I was ill-prepared for the numerical python section, since I did not have much experience in writing smart tools. The time was lost for me, attempting to catch up and learn as much as I could to reach the point that most of the class had started from. Having the FSL staff as a learning resource was useful, however.

Had many questions answered...even ones I didn't know I needed answered thanks to other people's questions. Very helpful!

We had one person dominate the time. The moderator needs to ensure that more than a couple of people get to speak. It was clear that the Western Region folks, for the most part, had little training here and so didn't really know what to ask.

Since there was little time for discussion (in Track B at least), this could have been a little less structured.

Questions and Answers was the first session Track A attended. Long before most of knew what questions we wanted to ask. Would have been much more useful if it was pushed back towards the end of the seminar.

It was too early in the workshop, and covered a lot of the things I already knew. I'm sure other people got a lot more out of it than I did.

Smart init looks like an essential process in being able to produce the massive amount of grid points needed to create the gridded database...along with smart tools.

This is the "bread and butter" of GFE. If we can initialize the model data to a reasonable output, then there may be little need for Smart Tools and/or Procedures. However, this may be wishful thinking.

I had learned how to do this stuff already, from Mark M's e-mail following the release of RPP13. It was still good to hear the formal presentation of how the system works.

This is good to know stuff, but could get dangerous. Each site can tailor their viewed output, but it may cause some coordination confusion.

Still seems a little confusing to me. I hope to do more with this over the next few months.

Something I have already been experimenting with, so I was anxious to learn more and this session fulfilled that desire.

This filled in a lot of gaps in my understanding and gave me a good idea of what smart init can do. Nice to know it is that easy to use local models if we can get the geography straight.

I prefer longer and more detailed lectures and watching someone demo it rather than trying to do it with a incompatible lab partner.

I'm still not sold on the merits of smart initialization in an operational environment. Our office rarely re-populates forecast grids with model data. Perhaps that will change if model output improves. The lab seemed disorganized. I don't recall having the time to complete the lab exercise.

I'm planning on taking advantage of the FSL smart tool repository. The examples directory and libraries will save us a lot of work.

I prefer longer and more detailed lectures and watching someone demo it rather than trying to do it with a incompatible lab partner.

Somewhat basic for me. Maybe better if tracks could have been separated into "Basic" and "Advanced"? That way the Smart Tool and other stuff could have skipped through the basic stuff for the Advanced track.

I'm already pretty familiar with the process, so it's a bit hard to evaluate. It was good to have to slow down and read through the exercises, to see what they contained.

Did not find the lab to be very useful, but the lecture was good. Gave me some ideas for local implementation.

I have already made several local changes using My Dialog windows to give the forecasters feedback. I also created a procedure to interpolate all of the modified temperature grids then pick off the MaxT and MinT without forecasters having to highlight and run multiple SmartTools. The class/lab led to a better understanding of the Numeric Python applications.

There was some confusion on what we were suppose to do in lab. Needed a little more up front guidance.

Nice overview, plenty of examples; I would have gotten more out of it if I had finished going through the prerequisite information before attending the course.

Again, I could have used more time on this subject, but, practice on station will help me figure it out.

Again, my lack of background experience hampered my progress during the lab, but I learned a lot!!!

I didn't know how many examples were in the GFESuite directory, so this was an eye opener. And also good to see that it wasn't as hard as I had originally thought to do.

What can I say. This is more flexible than dealing with the MDL IGR(matrix). You can make changes "on the fly" and see results fast. With MDL's IGR(matrix), the field may not see any changes until 6 months to 2 years. And that's assuming there isn't any problems. The python code is pretty easy to grasp and change on the spot. I like the fact that ALL products come out of one piece of software. It has some much possibilities.

Worded forecasts will always be how a large part of the population gets their weather info. Getting from grids to text I'm sure will require a lot of work.

The lecture was good but went very quickly and some went over my head. Would have liked to see more technical info on the Smart text products and phrase products. The basic tables could have been brushed over or skipped.

Once again, a part of GFE that I've done a lot of work with. The presentation was little more than a review for me.

Had spent considerable time in the prior two weeks working on this, so much of this was a review. Did get a couple of new ideas.-

Good overview, but might have helped to go through an exercise in class instead of just showing slides of output that could be created. If the text process can be refined, most sites would welcome the switch from MDL's IGR matrices.

We spent a lot of time talking about MDL vs. FSL here. It seemed that the tools here were quite flexible. A good introduction to them.

Wasn't able to follow everything, but got general idea; better Python background would help me here.

Not something we will be using at my office, but nice to see what the field offices have at their disposal.

We are using the MDL text formatters with IFPS. This was not useful, other than to see what the rest of the NWS is up to, and perhaps what we might use in the distant future.

Wish I had more time to try the exercises, but it did a good job to get my interest up. I will be playing with the text generation over the next few weeks.

The lab seemed very basic and did not cover the more sophisticated text products as much (smart, combo, phrase). I let my partner do them since he had not had as much exposure to GFE.

As with most of the labs...it was a little short. But it was a good way to see the text tools in action.

Due to the lecture part running over and people's seeming disinterest in the lab exercises, this part was not completed.

Always good to get tips straight from the developers mouth...and the other participants as well.

Learned a couple of things that will be nice use. Would like to have learned more about the various interpolation schemes, and the pros/cons of each.

Frequent interruptions from audience may have limited what was covered; lecturer didn't seem to have much prepared (wanted it to be more "interactive" and free-form with audience, which is fine, but I don't think it came off that well).

Don't take the above rating as a criticism. I think it's best to have fast paced sessions, especially after lunch. However, I may be contacting some of you for extra clarification.

There was a lot to cover, and cover it we did. By the end of the workshop, I was mentally drained.

Lots of great information, but coming at us a little quick. I'm thankful for the reference notes to use back here at the office.

A lot of information given to the student over the course of 2.5 days. While an intermediate/advanced student would have little problem, I think a beginner would be quite overwhelmed.

I think the pace was appropriate given the mix of people/backgrounds involved; better to be a little fast, than slow. Even as a newcomer, I was able to understand most of what was presented, and learned what I need to do to get up to speed.

But then most people seemed a bit more advanced with IFPS/GFE/AWIPS than I am. So I am not complaining in the least. I was able to get about as much as I could if it were a little slower too.

Because of my recent exposure to IFPS and the GFE, the pace was a bit fast for me. However, the pace was probably about right for those who had more experience with the GFE.

Some topics seemed to go too fast (with assumption that everyone had been involved with RPP for some time), but overall the course pace was fine.

Was generally good, although repeated comments by one attendee brought pace slower than I would have preferred.

The training was intense but not overwhelming. Three days was a good length. Any longer and everything would start to blur.

Hands-on time is always a good part of these workshops. In this particular case, it allowed the pace of the workshop to slow down, so that attendees could begin to process the material that had been covered.

Experience level differences between lab partners hindered this from being the best it could be. Having enthusiastic FSL developers in the lab room to help out/give tips/perspectives was REALLY great. Thanks!

Python still doesn't come to me 'naturally' so it helps that we get answers to the exercises which I can use to see how actions are coded and then try to modify existing scripts to fit my needs.

Logistics-wise the labs might have been more effective to have all of the workstations in one area.

We had a little trouble getting started, and then we got a "gotcha" or two which held us up so we did not finish all the labs.

It was good to do the exercises, but I had already looked over the Smart Tool exercises when RPP13 was released, so some of the time seemed wasted. the text lab was good, but some could have been covered in the seminar when the group could have asked questions and had some discussion.

You can never have too many hands-on exercises. I believe hands-on exercises speed up the learning process several times over just attending lectures. The more exercises, the better.

They were okay, but it took awhile to figure out how to get started in some cases. Exercises good to take back to the sight for training.

I would have preferred to have my own workstation, and think my lab partner probably would agree.

I prefer longer and more detailed lectures and watching someone demo it rather than trying to do it with a incompatible lab partner.

Thought they were the weakest part of the workshop. Spent too much time typing /troubleshooting syntax, instead of using what we learned. Personally, I'm learn more on my own trying things at my leisure. Would be useful to "kick the tires" of the new features, but simulating a coordination/developing smart tools is not a good use of limited time.

These were some of the best handout I've ever received in the NWS. Liked the spiral binding, and that we had the speaker presentations ahead of time. Was able to follow along and write comments in handout. Outstanding.

This is very helpful material for any IFPS/RPP focal point. Good quality image reproductions. That was always poor at the training classes in Kansas City.

These were excellent. Only improvement would be some tab or table of contents relating to the color paper. It was difficult finding the slides at the beginning of the lectures.

If you mean hand outs by the booklets we received...very good! If at first you don't succeed...look at the answers! I work backwards from there...

Terrific help, especially since you gave us the answers to the exercises. We can now use this data at our home stations.

Smart Initialization, Smart tools, and conversion to numerical python to speed them up. Probably most useful is direct interaction with the developers. Interaction with other RPP participants valuable as well.

The group training sessions, especially on writing in numerical python, getting info on the latest GFE enhancements and tips, IfpImage info, and data logging.

The numeric python and Intersite Coordination sessions. The Smart Initialization talk was pretty good, too.

The training book is very good...and I like having the exercises included to help understand writing of smart tools etc.

Interacting with the programmers and other attendees. I haven't had a chance to thoroughly read all the GFE documentation (have forecasts to issue :) so hearing about some of the configuration tips/tricks was very useful. Also will put to use some of the numeric python info.

Python and Numerical Python, Smart Tools, ISC. Text Product Infrastructure, Other GFESuite Programs

For me, using the Linux software. A great primer for having to do it here locally in the very near future.

Interaction among students and with instructors/developers is very valuable. This is lost in teletraining.

The Python and Smart Tool parts were the most useful for me since I am just getting into learning these.

The numeric python section was very helpful to me. It helped with some key basics I needed. The smart tools section was also very helpful.

Since we're part of the central cluster NDFD... the stuff on ISC was particularly useful. But all the topics seemed to be relevant.

Those that focused on text generation, smart config, and the development of smart tools. Customization is going to be a big deal in areas of complex terrain. So developing those skills will be critical for those out west in order for this new approach to forecasting to succeed. I also thought the discussion about sharing the locally developed enhancements was good.

Finding out what is happening and will happen with GFE. The stations not on the RPP need this kind of training too.

Nearly every aspect was VERY useful. Having the developers right there as the instructors was wonderful as they were as knowledgeable as you could get. Going over the progress over the last two years was helpful since I had not attended the meetings in the past. The web site and prepared notes were great additions to the workshop.

The hands on aspect. listening to other attendees talk about issues from the field. changing instructors frequently.

ISC. The reason I say this is because it seems very likely that this feature will change significantly in the coming months and what we learned may no longer apply. Still, it was a necessary exercise so that the developers could get our opinion on the software/process.

Progress and New Features. If this workshop is for people that have used the GFESuite, then most likely they have used the most recent GFESuite, before the workshop.

For local purposes the intersite coordination was least useful...although I don't think it wasn't needed or informative.

[one participant's] thinking out loud. This really limited the amount of time available for others to ask questions and give comments. Most of his comments and questions were legitimate, but he needs to know that in a workshop with this rapid of a pace, verbalizations of what is running through your brain at the time need to be limited.

Unfortunately, the labs. We had a little trouble since both of us were unfamiliar with the Linux version of the software, and we did not make it through all the labs completely.

Split tracks didn't allow as much interaction with other students, but on the other hand it kept classes smaller.

It would have been nice to have the training last a day longer so that more detail could be added.

I would have preferred less discussion and lectures and more lab time. I believe the class should have been extended for a least one more day and this would have partly solved this problem.

Text Products formatters... but ONLY because someone other than me will likely write them... so am not recommending that the topic not be covered.

The part of the meeting on the first day, where we were all together in the big room. Maybe needed a 'facilitator', so it didn't turn into people taking the floor for so long.

Not many really. The hands-on were shorter than I would have liked...but still quite useful.

Configuration was not as useful b/c there was a lot for me to try and absorb. Others more familiar with the GFE may have had a better experience.

Since we have just started working with GFE, some of the more advanced aspects were not useful at this time(although they will come in handy later).

Smart Tools, maybe a group brainstorming session would be appropriate?? Then have teams develop the tools.

It may be time to start gathering the various methods and solutions that sites have come up with into some standard practices. Define what web imagery we expect everyone to produce, and standardize the way that it is done. Also formalize text product formatting. There is no shortage of things that still need to be done.

The more help I can get in writing smart tools and procedures the better. I wasn't aware there were so many examples included in the software, and although I haven't had a chance to look through them since returning, I'm optimistic they'll aid me considerably. I'm best off when I have examples of other people's work to work from.

What is the most efficient way to get a forecast out? This would imply knowing all the ways to get from point A to point B. Would like to have had more time on python, but that probably would only benefit a few.

The big picture with regard to WHERE the science is being done. Do we aim to take ALL the AWIPS data (sat, radar, sfc obs, etc.) and model fields, pull them into the GFE, and try to re-integrate them in some meteorologically correct way in the GFE to get the best answer? Do we use just SOME of the data and get a sort-of-good-enough answer? Or do we look at doing most of the science on AWIPS where ALL of the data is there with all the data integration and manipulation tools available and somehow figure out (note BIG somehow here!) how to best get that 'fully-processed' information into the GFE grids? This is already becoming a factor as sites are asking for sat data in the GFE, climo grids in the GFE, and so on and so on. Are we creating a 2nd AWIPS...a merging of GFE and AWIPS??and send some sort of forecast grid to the GFESuite from it - with final refinement

Smart Init. Which upgrades apply to which versions (especially with programs like IFPImage where some switches do not work in older versions)

Smart Tools...this is what should help the forecaster with forecast construction. Config files...what changes can produce the best images/data for the forecaster. I was in Track A and missed the GFE Tips/Tricks class. This should be provided to everyone since this could help reduce the effort required to complete a forecast in bad weather situations. Text output...only if more FSL support is provided.

Adding more models to the initialization. Such as Work Station Eta and MM5 models. More information on the serverConfig changes.

The text product section needed more focus. It appears that it will eventually be a more efficient way to generate products and I would have preferred more lab time in this section.

Text Product generation. Would like to see more of the analysis procedures, and how to develop these.

Not sure. I was hoping to learn more about setting up the gfeconfig file to manipulate the .png files. I still have some trouble with some of the syntax there. I have mostly done work-arounds with shell scripts.

Text products. This is already done by MDL. I can't understand why we should be reinventing the wheel. It is really crazy that we should all be doing different text products. Everyone should issue standard formatted products PERIOD! Western/Central Region folks think they are so much better than the rest of the country. Did anyone ever run this by Jack Kelly?

Nothing needs less focus. All of the capabilities of GFE need to be recognized, so they can be incorporated into solutions to IFPS issues on a national scope.

Not sure smart initialization was worth the time. Maybe. We find it most efficient to edit the previous forecast, so model stuff is less useful.

You will always have new office program leaders, so dropping some of the topics may mean new people miss out on something everyone else expects them to know.

Smart initialization, since most of the time previous forecast is used as the basis of a new forecast

I know of no section that needed less focus. I thought we moved through each section quickly.

People seem to have questions, even on the things that seem like they've been beaten to death, so I can't say there is probably anything that needs LESS focus.

This was the first time ever that I attended a NWS sponsored training that the instructors really knew the topics completely and so detailed. NWS training center could never provide training like this. Every time I go to NWSTC, it seems like I usually know more than the instructors. All of the staff should be commended for the outstanding training they provided and I am totally impressed about your knowledge. Thanks for a great experience. Hope to be able to attend a future session.

The FSL staff has been doing a great job. These workshops are always productive and valuable.

I must say that I'm always impressed with FSL's ability to support this level of training. The personnel in Mark's group are outstanding and I doubt they ever receive enough credit! Great job!

This whole process is well worthwhile to the field. I am impressed with the RPP process. Also, it is a very good idea for the programmers(creators) to interact with the field(users). This is the most critical. This way the field gets almost everything they want in the software, and can offer improving suggestions. In my opinion, this is brilliant way to run a program! I wish all NWS programs were run this way.

The experience was generally a good one, but an awful lot of stuff was covered. It was good to get the chance to talk to other GFE users, and hear there comments, and exchange information with them. Thank you for the opportunity.

Feel it is absolutely critical that these continue. The interaction between the users/programmers is vital to making IFPS work. Hope that this interaction can continue.

It was fantastic overall. The progress shown in the RPP is a nice change from the sluggish pace of AWIPS improvements. You guys are almost two years ahead of our software. I hope we can begin to see this stuff in the field sooner! We're excited to see it!

I only became involved with GFE over the past 1 ½ months, so I felt that sometimes the lectures were above my level of knowledge. This will continue to be a problem as current office Program Leaders move on to other sites and jobs leaving the program to less experienced persons.

The "night out" was very good. Although the two-track system worked well, I would have liked to have more time with the entire group together. Daily wrap-up sessions perhaps?

Overall, the training and documentation seems to miss important specific details in a number of areas.

Overall, very positive. Being new to RPP, I was left with the impression that we were behind some other offices in terms of RPP development and use operationally, as have been working more in the MDL framework. I hope that MDL and FSL can find a way to work together in putting out effective software for me to do my job more effectively. I was extremely impressed by the programmer/user feedback process that goes on between FSL and the users, and the way GFE suite opens avenues to the field for further development. I believe strongly this will have a very positive effect, and speed development in the long run.

Very good training sessions. If had to do over... don't know of any significant changes I would make to the agenda you had. I suspect most of the participants had a higher interest in different components of the GFE... so a relatively comprehensive range of topics was necessary.

The training was well worth it. The course needs to be conducted again, especially for the Western Region. I know quite a bit more now than I did a couple of weeks ago. I think as we gain experience with GFE that future WR participants will get a lot more out of the course than I did just because I was a novice.

It was great. I came back with a ton of things on my 'To DO' list. And that is a good thing. I don't always have time to delve deeply into all the new things that each build can do, and this gave me a huge jump start. thank you!!

The workshop was extremely beneficial to me as I have a much better understanding of GFE and how it fits into the bigger picture. Every segment of the workshop added to the knowledge that I already had and also gave me resources for additional info. It was an opportunity to meet with people from other regions and to compare/contrast operations. This is always a big plus. I feel the information gained will be of great value as we incorporate GFE/IFPS into our operations/NDFD. Great Job!

Very good. 1000 times better than the training we got from the training center in Kansas City.

I think it was very helpful for me. I am still something of a neophyte with the GFE. This training definitely helped me get to the next level.

Several RPP workshops have been held prior to this one. It was obvious who was "in the loop"and who was not. I felt like an outsider. It almost seemed like you should have had two workshops...one for the long time RPP folks and another for the new people. During most of the discussions, I had no idea what people were talking about, so it was difficult to contribute. Still, I appreciated the opportunity to attend and meet people and was able to learn a great deal about GFE. More time should have been left at the end to have a group discussion about various aspects of GFE. The group discussion at the end of the workshop was the most valuable part of the whole thing.

Always extremely valuable (even for a region weenie!). Thanks! So sorry I missed the deadline on this!