> O.K. I think we have feeds trimmed down to a reasonable size(correct me if > I'm wrong), The realtime statistics being reported by SHU show a reasonable average amount of data being received. http://www.unidata.ucar.edu/cgi-bin/rtstats/rtstats_summary_volume?shu.cup.edu Data Volume Summary for shu.cup.edu Maximum hourly volume 2348.128 M bytes/hour Average hourly volume 822.102 M bytes/hour Average products per hour 66208 prods/hour Feed Average Maximum Products (M byte/hour) (M byte/hour) number/hour NEXRAD2 268.352 [ 32.642%] 358.047 14163.261 HDS 176.182 [ 21.431%] 429.760 15054.500 CONDUIT 156.176 [ 18.997%] 1532.144 1274.261 NNEXRAD 84.134 [ 10.234%] 121.316 10328.783 NIMAGE 83.692 [ 10.180%] 210.545 7.239 IDS|DDPLUS 22.742 [ 2.766%] 28.486 25216.609 UNIWISC 21.858 [ 2.659%] 28.264 25.957 DIFAX 5.611 [ 0.683%] 22.902 6.870 FSL2 1.893 [ 0.230%] 2.086 21.174 GEM 1.451 [ 0.176%] 22.248 100.174 NLDN 0.011 [ 0.001%] 0.058 9.413 The time series graph of volumes shows that there is a peak every 6 hours which is completely dominated by the CONDUIT data that you are ingesting: http://www.unidata.ucar.edu/cgi-bin/rtstats/rtstats_summary_volume?shu.cup.edu+GRAPH Latency plots for the various feeds show that you are by-and-large receiving data in a timely manner. > and I'm trying to cleanup our system. If the latencies you are seeing are acceptable to you (again, they seem to be OK, but not fantastically low), and if the data you are receiving represents the set of information that folks feel is needed, then I think you are where you should be. > It looks like we want CONDUIT for sure, and I've trimmed it down some, but > one thing I > realize is that we don't seem to be processing CONDUIT into a file. Is that > correct? I don't know what pqact.conf actions you have implemented. At the time that I last looked at your machine, you had no processing setup for CONDUIT data. > Do we need to file CONDUIT for McIDAS to use? No. When you get around to installing GEMPAK, you will want to start procesing the CONDUIT data. Since I saw an email from Chad that indicated that you should hold off on the GEMPAK installation for awhile, you may want to stop your CONDUIT ingestion. Then again, you may want to keep ingesting it so that your IT folks will get used to the volume of data flowing into your department :-) > Could you be a little clearer about the "WMO" feed. What is WMO, data? Here goes: - First, all of the feed names are mnemonics - second, some feed names actually represent the union of other feeds. We refer to these as compound feeds. The mnemonic 'WMO' is one of the compound feeds. It is the union of all products contained in the 'IDS|DDPLUS' (global observational data) and 'HDS' (NCEP model output, almost all of which is in GRIB1). > and do I need HDS I believe so, yes. > I'm not sure why ldmping doesn't work, Hmm... Yes, I see that an 'ldmping' from the LDM on my workstation, yakov.unidata.ucar.edu, to your machine, shu.cup.edu, does not work: address@hidden ~]$ ldmping shu.cup.edu Oct 24 20:56:32 INFO: State Elapsed Port Remote_Host rpc_stat Oct 24 20:56:32 INFO: Resolving shu.cup.edu to 18.104.22.168 took 0.000543 seconds Oct 24 20:56:42 ERROR: SVC_UNAVAIL 10.001530 0 shu.cup.edu h_clnt_create(shu.cup.edu): Timed out while creating connection The cause of this kind of a failure is typically related to a firewall setting on the receiving LDM's side (i.e., CUP). > but is it necessary? No, or, at least, not if everything is running OK for you. If, however, you have problems, our ability to help you troubleshoot them is severely diminished by our not being able to do an 'ldmping' and/or 'notifyme' to your machine. > I can't seem to get notifyme working either, but is it necessary? I verified that I can not do a 'notifyme' to shu either. My comment is the same as for 'ldmping'. > How can I install McIDAS on other workstations on campus, and make the data > available from > Shu? You can install McIDAS on whatever machines you want (Unix, Linux, or MacOS-X). The procedure will be mostly the same as it was on shu.cup.edu: - create a 'mcidas' account - download McIDAS to the ~mcidas directory - set values in the shell-specific configuration files (e.g., .chsrc for C and T shells; .bash_profile for Bash, etc.) - 'source' the shell-specific configuration file to set needed environment variables - unpack the McIDAS distribution using 'mcunpack' - CD to the ~mcidas/mcidas2007/src directory - build the McIDAS-X part of the distribution: cd ~mcidas/mcidas2007/src make -- OR -- make mcx Both of these build the McIDAS-X portion of the distribution. There is no need to build the McIDAS-XCD portion of the distribution since the decoding is being done on shu.cup.edu. - install the newly build code: make install Some differences in what is needed in a client build from a server build: - in the client build, you do not need to define ADDE datasets as these will be read from shu.cup.edu - you do not need to run the McIDAS configuration script 'mcxconfig'. Instead, you can create the Client Routing Table entries needed to locate datasets on shu.cup.edu: <as 'mcidas'> cd ~mcidas/data cp DATALOC.BAT LOCDATA.BAT -- edit LOCDATA.BAT and set the names of the machines you want your users to go to for the various datasets - make the client routing table entries active: cd ~mcidas/workdata batch.k LOCDATA.BAT - do the needed configuration for each user account that you want to run McIDAS: - create the user account - create the directories ~/mcidas and ~/mcidas/data in the account as the the owner of the account - modify the user's shell-definition file to include needed McIDAS definitions (see the Unidata McIDAS-X Users Guide for the 1-2-3 on how to do this) - log off and log back on and verify that the user can start a McIDAS session that uses the code built as 'mcidas' and client routing table entries defined by 'mcidas' (see above) Setting up a new McIDAS user should take on the order of 5 minutes. Cheers, Tom **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: XRR-599672 Department: Support McIDAS Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.