Activity for Mike Romberg
-
Mike Romberg posted a comment on ticket #38
RHEL8 is currently running python-3.6 (according to google). So, it might work. But I would not be surprised to find that an adjustment or two might be needed for the older packages in RHEL8. The installation steps should be the same as fedora (RHEL is based on fedora) found in the README. In particular you will want to check the list of "Requires" packages found in the config/gfe.spec file and make sure they are installed before attempting the build.
-
The HLS is there when I configure 1.17.1 for the LCH site. It won't run without the patch that was recently checked into the tree. But it is there. What version of the gfe are you using?
-
The HLS works for me with site LOX. However you will need the patch I just checked into git. The next release will have this fix for the HLS.
-
Not all sites are configured to have all products. The gfe uses information in the etc/afos2awips.txt file to see if a given site has a given product. For example BOU and CAE don't have an HLS product. But LOX does. I usually test with the default BOU site so the HLS is not up front in my testing. But I did just do an install with site=LOX and the HLS is there. GenerateCyclone requires products from the national centers. There is currently no way to ingest these products. So, It is expected that...
-
Your build is still not sucessful so the make install target is failing. What errror do you get with just plain 'make'?
-
gd-devel is in the config/gfe.spec file. You will need to make sure that every package mentioned in a Requires line there is installed.
-
Install the gd-devel package. It looks like I missed that in gfe.spec file. I'll add it there too.
-
Attached is the fixed linkHeaders script. It will also be checked into git. You should be able to copy it over the one in your tree and then still use the testing directory name.
-
I think my linkHeaders script (the one that does the work in 'make links' hates the testing directory name. Normally it will skip header files in test subdirectories. But I think it is skipping everything in your whole tree due to test being part of the testing name. This is obviously a bug. I'll fix this. In the meantime try renaming your testing directory to something without the word test in it and see if that fixes the build. When make links runs it should print out many dozens of headerfiles....
-
Try running: make links make The above error is almost certainly caused by needing to run make links (which creates some sym links to make finding internal header files easier).
-
I just released 1.17.0. It should work on fedora 40 and 39.
-
I'm guessing you must be using fedora 39 or 40 with a newer gcc. I fixed a bug related to this a while back. I'm pretty sure that is what is going on. I'll release 1.17.0 today and that should build clean on fedora 39/40.
-
Version 14.4 is kinda old. If you are attempting to build 14.4 with a newer compiler then that is probably the problem. Try a newer version of the gfe. Version 16.2 is the latest. However I am very very close to releasing version 17. I may put that out today. So, you might want to wait and try it. It has many many changes relative to version 14.4.
-
Before doing a build, you need to run 'make links'. So, try: make clean make links make install
-
Fedora workstation should be fine. The README file contains some notes about building, installing and running things. If it would be helpful, I could include some pre-built rpms for fedora in the next release.
-
The Graphical Forecast Editor does not run on windows. So, you will first need to install Linux. I recommend Fedora linux.
-
Generating lower case may not be all that difficult to do. I'll look into it. The formatters here predate the addition of the impacts wording. So, they don't support it. It may be possible to run newer formatters which do generate these IBW impacts. I just don't know how compatable they are or not as I don't have access to the newer product formatters.
-
It would be nice to have more model data. The biggest hurdle I have in adding more is the very sparse amount of documentation on the NCEP site about the data . I was able to get NAM and MOS going with a very large amount of trial and error and educated guessing. But it is alot of work with little documentation. To get a new model into the gfe I need to know: Where are the grib files located? What it the base URL on the ncep site to find them under? For example the nam files are found under http://nomads.ncep.noaa.gov/pub/data/nccf/com/nam/prod/...
-
I don't recall anything major (gcc, python, swig) changing in any significant way between fedora 34 and 35. So, the gfe may very well compie and run fine on it. If not, fedora does have a pretty painless way to upgrade the whole distribution on the command line. It is like three commands (and a bit of time).
-
There are several different menus which can have weather keys in the GFE. Can you be a bit more specific as to exactly which menu is giving you trouble?
-
It is very possible that older versions may not be compatable with newer versions of linux distributions. In particular, Fedora linux updates their packages at a fairly agressive pace. So, it usually contains the latest versions of gcc, python, etc. I update the gfe code to work with new versions of these packages. But, it is generally not worth the effort and headache to make the gfe code work with both the new packages and the old ones at the same time. If you are attempting to use an older version...
-
Try using version 1.14.4 for products using Hazard grids. There was a bug (which was fixed in 1.14.4) which caused new hazards to not be picked up by the formatters. I was able to generate a FireWx product now.
-
For 2, the simplest way to get some model data (spcifically NAM) is to: (as root) mkdir /scratch chmod 1777 /scratch Then (as the normal gfe user NOT root) gfei -m ifpIngest This command should just be left alone to run. It will run forever and you need to keep the window you start it from open. It looks for the latest model run about once every hour or so and downloads it. It may take up to a few hours to pull the first run in depending on exactly what time of day you start it on. The rest of the...
-
Point your web browser at http://localhost:8044/ Specifically: http://localhost:8044/rest Here you can use the machine name the ifpServer is running on for localhost and the port (if it is not the 8044 or 8042 default). The ifpserver *is* a http server. The gfe and every other client comminicates with it via this web interface. So, one could write scripts in python/perl/ruby or whatever you want to download (or even upload) grids to it. This is how I would pull grids out of the server for use elsewhere....
-
It should no longer be necessary to be in practivce mode to have the transmit be a simulated transmit. I'm reasonably sure I hardwired all transmits to be simulated as (of course) there is no way for them to be any other kind in this GFE.
-
The 'publish to official' menu item will be greyed out when the gfe is started in either PRACTICE or TEST modes. Normally, all products are generated from the offical database. The offical database is considered "The Forecast". When grids are saved they are written to the forecast database. The forecast database is a work in progress. No data from it are used to generate products. You move data from the forecast database to the offical database by publishing it. The idea behind PRACTICE and TEST...
-
Nice! When you do a 'make dev' or 'make install' you can change variables like site, port, host,etc like so: make dev site=GRR
-
This file is pretty huge (it is machine generated by swig) and compiling it takes a fairly large amount of memory. I suspect you are running out of memory durring the compilation of this file and the kernel is even taking out your terminal due to it overcommiting memory. How much memory do you have on this system? It there any swap space configured for it to use? The free command should show you both of these. I'm guessing you may need about 4gb or so (a guess) to deal with the compilation of this...
-
The goofy markup code swallowed my'star characters. So, the ls commands did not do what they were suppose to. Never the less it looks like the culprit is AFPSDB_wrap.C and AFPSDB_wrap.o. The C file is generated by the swig utility. I wonder if swig somehow created and empty file. What does ls -l AFPSDB_wrap.C show? Then (in the gfePYIntr directory) do a make clean and verify that the clean removes AFPSDB_wrap.Cand AFPSDB_wrap.o (It should). Then to a make AFPSDB_wrap.o and postthe complete output....
-
I'm fairly certain that something is going wrong with the compilation of the swig gnerated file AFPSDB_wrap.C. What is the output of this on your system cd gfe/gfePyIntr ls -l .C .o file AFPSDB_wrap.o
-
Ah ha! That was my theory. It also happens to explain the first batch of missing symbols which should have been pulled in by this file. I wonder if it was corrupted in one of your earlier build attempts? Regardless, I would try a complete rebuild: (from the top of the gfe tree) make clean make links make The clean should remove all the object files (and swig generated .C files). You might get away with just cleaning gfe/gfePyIntr and rebuilding that. But it is possible that the other swig generated...
-
Hmm.... We are both using fc35 and have the exact same versions of gcc and ld. Yet the linker is exhibiting different behavior. I got to 35 via a dnf system-upgrade. Did you do a fresh install? Maybe my upgrade left something behind. I kinda remember that some binutils applications have configuration files scattered around about. I wonder if the different behavior can be explained by one of them. I'll keep looking. In the meantime, we are down to a single symbol not being found. It should be here:...
-
For some reason your linker is being more selective than mine. Mine is pulling in more symbols (even if they are not needed right at that moment). I'll need to figure out why that is going on so I can duplicate this on my end. In the meantime, try editing config/internal.mk -GFE_DIRS = editTool gfePyIntr dataMgr msgHand parm visual graphics +GFE_DIRS = editTool visual gfePyIntr dataMgr msgHand parm graphics This will link the visuals before the dataMgr library and should fix that specific error....
-
Hmm... It is not finding symbols from the gfe's own internal libraries. The compiler line doing the link is partial in that hastebin: /usr/bin/c++ -Xlinker -export-dynamic -Wall -Wextra -O3 -pipe -g -o gfe gfe_version.o main.o -L/home/fedora/Downloads/gfe-1.1 I'm going to assume that the rest of it is ok and that the linker is looking for all the internal libraries. This must mean that they (the internal libraries) are incomplete/corrupt in some way. Maybe something went fubar in an earlier build...
-
Sounds like a library linking related problem. It would help if you posted a few of these error messages. I can probably guess which library is involved from there.
-
I've checked in a few commits that fix some tool/procedure related issues into the git repository. Many should be working now. I'll kick the tires some more and make another point release soon.
-
Thanks for reporting this. There was a bug in the edit tool activation code. I've fixed this in 1.14.1 and the pencil tool now seems to activate and function.
-
You can only have one site per ifpServer. However, one could run two or more ifpServers each configured with a different site. Any gfe could then connect to any of the servers and thus be working with a different site. Switching this on the fly (switching servers while a gfe is running) could be done in theory. But at the moment is not supported. It is an interesting idea to think about. I'll look into how difficult this would be to support.
-
I've just pushed a bunch of changes to the sourceforge git repository. This is the code I'm now working with on fedora 31. Try again using a copy of what is now in git. When I get some time, I will put togeather the final bits and make a full realease out of it. But for now the git repo should be ok to use with fedora 31.
-
The GHG monitor appears to be working (I'm not an expert in using it). There was a problem withthe VTEC decoder caused by python3 changing the way subpackages import. I fixed that along with the other problem. After those fixes I was able to create a SV.A:1 area in the hazard grid. Publish it and create a convective product. After the convective product was transmitted (and thus run through the vtec decoder) it (SV.A) shows up in the GHG monitor. Give it a go and let me know if anything else does...
-
Try the convective watch again using what is checked into the master branch. I found and fixed a bug that was created when the code was updated for c++14. After fixing it, I was able to run the formatter and generate a convective product.
-
The site used to configure the gfe is in the file etc/gfe/BASE/siteConfig.py. It is the variable GFESUITE_SITEID. You can change it there. You can also specify it when the install is done by using the site paramater like so: make install prefix=/your/directory/for/install site=OKX And the makeInstall script will modify the siteConfig.py file for you.
-
It seems that compresslevel is a python 3.7+ feature. I've removed that option for now. This latest batch of patches are a push to get namespace packages working out of /etc/gfe/BASE and /etc/gfe/SITE. The idea is that you can place things like init modules in a directory /etc/gfe/SITE/ifp/init/MyNewInitModule.py
-
I'm guessing you may be reasonably close to a working native gfe Scott. When I did it years ago, I remember something along the lines of Tcl/Tk Tkinter on osx having both native and X11 versions. The gfe for sure requires the X11 versions. The widgets (buttons, scrollbars, menus etc) would be fine with native widgets. However the gfe's drawing code is all X11 and asks the Tk frame widget to adopt an X11 window to display them. This may change when I get around to converting these graphics to opengl...
-
Ah, yea. This may be troublesome at the moment. I've been moving alot of the gfe's python code into packages (the gfe used python before python even had packages :). So, all of the init code is not in a package called ifp.init. When installed, most of this code gets placed into a file called gfe.zip. And this all works well. However, it does make it tricky to extend the system with a new init module after things have been installed. What I need to do is modify the init package to be what python calls...
-
The rpms are a convenience for those who don't want to locate all the build dependencies and install from source. They are certainly not a requirement. The rpms that are available for download only go back to like fedora 26. So, they will not install on fedora 21. Your best bet is to use a more recent version of fedora (if possible) with the gfe.
-
When the link bombs, it is complaining about missing symbols that should be in the file IFPServer.o (note the caps). The file ifpServer.o has a similar name and mostly contains the main() function for the server. The meat and taters is in the file with the capital letters. However, I did not see this file being compiled at all when I searched your gfe_make_output. So, I have a few questions and things for you to try. Are you using gnu make? If not, you really, really should be as I've never tested...
-
Hmm... The missing symbols from the IFPServer class should be there as the IFPServer.o object file is clearly on the link line. You do have some other extra include (-I) and library (-L) stuff there which I assume you added in to the CXX variable. But I don't think they are the trouble. I'm not all that familiar with the osx linker and it is possible that there is some wierd stuff going on with it and the python link flags (-export-dynamic). It is very possible that a somewhat different linker flag...
-
There are at least two netcdf c++ libraries. The gfe used to use the really ancient one which is what I suspect you may have installed. I've ported it over to the newer netcdf-4 one which uses some more modern c++ featues (and is supported by the netcdf folks). On fedora, the package claims to be: rpm --info -qf /usr/include/netcdf Name : netcdf-cxx4-devel Version : 4.3.0 I have no idea if this is pre-built/packaged for osx. But the download page seems to be here: https://www.unidata.ucar.edu/do...
-
Looks like the version of clang you are using does not implement that experimental new class. The clang in fedora 27+ does. Luckily, LogEnv.C is not really being used. So, you can simply remove it from the liblogStream.a in the Makefile and move along. I have built the gfe with clang. But I don't use it all the time. Since you are already trying to build the gfe on a platform it has not been run on in over a decade, it might be a good idea to use gcc (version 7 or 8) first. I don't really know much...
-
The man page here on linux (for the gnu C library) mentions two versions of basename. The first and default one is POSIX and has a signature: char basename(char ) The second is a GNU version never modifies it's argument and reads: char basenae(const char ) With the gnu C library it looks like you get the gnu version if you don't include libgen.h The compiler is of course finding the POSIX version on osx and complaining about the const problem. Which is good because if it compiled it it would segfault...
-
Quite a while back (years ago) I was able to compile and run the gfe on osx. It did mostly work and was not too difficult if I remember correclty. The code has probably become a bit more portable since then. So, it should (in theory) be doable now. However, I no longer have access to any machine that runs osx. I know osx is loosly based on one of the BSD variants. I could probably make it work on those. But there are probably osx specific quirks that would need to be addressed in the makefiles to...
-
Quite a while back (years ago) I was able to compile and run the gfe on osx. It did mostly work and was not too difficult if I remember correclty. The code has probably become a bit more portable since then. So, it should (in theory) be doable now. However, I no longer have access to any machine that runs osx. I know osx is loosly based on one of the BSD variants. I could probably make it work on those. But there are probably osx specific quirks that would need to be addressed in the makefiles to...
-
Major Install Issues
-
should be fixed for fedora 28
-
There is nothing special about any of the executables you can run from the gfe's Scripts configuration file entry. So, one can create a script or executable with whatever programming language you want to do whatever you want and add it to the gfe config file "Scripts" entry. Your script will then show up in the gfe's menu. It would probably be easiest to write the script and get it running on the command line first. Then add it to the gfe config file after it is working. Python has alot of modules...
-
The nam is hourly for the first 37 grids. I guess this is the initialization and then 36 forecast grids. Then it is every three hours to the end. You are correct in that the part of the ingest script that downloads files does not care at all about forecast times. It uses a simple process of finding a list of all files in the remote directory. It then filters those named files down to a list that apply to the current expected model. This sublist of files may be complete or incomplete as grib files...
-
Just got around to updating my machines to fedora 28 this weekend. Looks like glibc finally got around to totally removing the last vestages of the old rpc code the gfe use to use. There was one last bit hanging around in the gfe's source code. Since it was not actually being used, I disabled it and things seem to be working on 28 now (very limited testing).
-
Thanks for the link! I think I may have bumped into the nam documentation before. Which is why nam is implemented in ifp.Ingest. What I failed to find is similar documentation for any other models :). As far as variable names go, there are three sets of names involved for the same data. First there is the name of the data in the grib file. Decoding grib is difficult, error prone and slow. So, AWIPS I had an ingest system which did that and stored everything of interest in netcdf files. Then everything...
-
The second error (you just posted) is a clear sign that a pickle database is corrupt. If you go to the /scratch/data/cdf/name/218 directory and do 'ls -a' you will see that there are more files in there than just the ones you see with a vanilla 'ls' command. In particular, there is a '.grib' directory which is used to hold the grib files while they are being downloaded and being decoded. After they are decoded they *should* be deleted. The second kind of file is of the form .XXXXXXXX_XXX.pkl which...
-
The configuration found in ingest/models.py is just the basics of what needs to be setup to sucessfully ingest a new model. The items in each configuration entry are as follows: mname - The model name url : The URL where the specific files (specified in fglob below) are found ddir - The destination directory. This is where the ingestor will place netcdf and work files) fglob - a list of glob patterns (*.txt, file_$.txt etc) that specify which files to get times - The model run times on a 24 hour...
-
I think what your are referring to as the white grid line seperating weather types is called a "bounded area" in the gfe. The Wx and Discrete data types are both considered bounded area types by the code. Looking at BoundedAreaVisual.C it looks like these can be enabled and disabled with the configuration option "BoundedArea_Boundary". It is '1' by default. And setting it to 0 should cause these to not be rendered. The ifp.Image program is simply the gfe code running behind the scenes without any...
-
Yea. I've bumped into the ETN number thing to playing around and trying a thunderstorm watch with a WCN. And just creating an ETN out of thin air with the GFE editor did not work for me either. It seems the code may be checking that the ETN is a valid number that already exists in the active table. If the number is not in the active table it gets rejected. That is my working theory. I think this is caused by certain products being in different fifedoms. For example SPC is the one who puts out thunderstorm...
-
Install from git issues
-
Creating Text Products
-
Most (probably not all) seem to be working to some extent. Open new tickets for the specific ones which still have problems.
-
IfpImage Not creating graphics
-
ifp.Image seems up and running again. So, closing this ticket. Open new tickets for any additional issues with the operation of ifp.Image.
-
Importing python config files to GFE
-
Populating models to grids
-
duplicate of still open ticket
-
OK. Your netcdf seems to be the correct version. So, that is ruled out as being the problem. My guess is that something got corrupted under /scratch/data/cdf. There is a file in there called template that is built from the .cdl in the tree at compile time. It is used as the empty starting point for each new model run. Either it is corrupt or the named cdf file in the above traceback became corrupt durring ingest. A really, really good way for the netcdf files to become corrupt is to shutdown the...
-
GHG Monitor not working
-
The basic product -> ghgmonitor seems to be working now. Create new tickets for any specific bugs in it's operation
-
Permission Erros inside GFE
-
should be fixed with new install script
-
IfpServer Permission Errors
-
install script rewrite should fix this.
-
Make Hazards and IFPImage not working
-
closing this one since ifp.Image, makeHazards and mergeHazards work at least in the basic sense now. Any specific issues with them can have a new ticket.
-
I enabled an old testing mode, I'd forgotten about. The transmit button now is marked simulated transmit. This is because it does not actually transmit anything anywhere. What it does do is store the product in products/TEXT and run the VTECDecoder on it to update the active table. This active table in no way reflects "real" vtec codes. It is just updated when this gfe has products which have been "simulated transmitted". It is more straight forward to do this than try to enable the gfe's PRACTICE...
-
I think I've managed to fix the GHGMonitor's configuration code. And I've also had some sucess with a standin for the AWIPS message handling system (MHS). I added a blizzard watch (BZ.A) to the hazard grids and then created a WSW product. The VTEC line was in this product. I then pumped this product through the VTECDecoder which worked after I fixed a few python3 bugs. But I did have to tack on a few lines at the top of the product: 248 FNUS75 KBOU 092326 FWSBOU I think this is an MND header (my...
-
The way the whole GHGMonitor/VTEC thing worked in the past was that when you hit "transmit" it copied the product to the transmit directory (which you can see is still working) and then called a script which was part of AWIPS to send it out over the MHS. This script is no longer there and this version of the gfe will never do this again. You can see the error message about the missing script on the terminal window when you press the transmit button. The VTEC table used by the gfe for things like...
-
The RAP example you are trying is a good place to point out the documentation problem facing getting this data into a form useable by the gfe. In this directory: http://nomads.ncep.noaa.gov/pub/data/nccf/com/rap/prod/ You will find subdirectories named with five differnt naming conventions. What is the diffence between these names? What do they mean? Some simple and obvious guesses could be made as to what some parts of the names mean. But it would be awesome if a document could be located that spelled...
-
I think there may possibly be an ncgen related issue going on with your build. See the other ticket related to this.
-
Adding the nomads URL is just one of many steps involved in adding new model data. So, just doing that alone is not sufficient to make the data flow. Things involved in getting a new model working: Identify which files on nomads hold the data we are interested in. This does not seem to be documented anywhere I can find at ncep. The file names must mean something to someone but the naming convention remains a mystery to me. Once the needed files are identified configure the ingest script (as you have...
-
The gfe is/was setup to store many files in a manner that makes upgrades to the software mostly painless. See the documentation concerning the BASE/SITE/user setup. The idea is that BASE files come with the system and are updated with a new version of the software. Files stored under SITE and user are not touched durring an update and are where customization and configuration is stored. HOWEVER, right now it is best to do a full clean install of everything from the build tree. I am modifying the...
-
It appears that the netcdf4 library is having an issue with the template file. The gfe source has several .cdl files which are a text files describing an exmpty netcdf file. Each cdl is "compiled" into a netcdf binary file durring the build by the /usr/bin/ncgen program. The empyt netcdf file is then used as a starting point for each new model run. It is the file called template mentioned in the above output. I wonder if your /usr/bin/ncgen is the right version? What does this command report on your...
-
Thanks for reporting this! It turns out that a revision control system written by a fellow who has his own unix kernel does not save full unix file permissions. Who would have guessed? Anyway, I'm now setting them on each file right after the install. I'm glad it seems to be working.
-
Sorry. I was not as clear as I should have been. You should change directory to the place where the gfe source code is. The one you cloned with git. That is the directory where you type 'make' and 'make install'. See what 'git config core.filemode' says when in that directory.
-
It seems git can be configured to either do the right or wrong thing with file permissions (probably for winders compatibility or something). Could you check this? cd /where/you/installed/GFESuite git config core.filemode Git should report either true or false with the above command. If it reports false then we have found the culprit. You can have git respect file permissions by setting it to true with the 'git config core.filemode true' command. If you have to reset this configuration, it is likely...
-
The points at which values are displayed are called samples. Groups of samples are called samplesets. To get ifp.Image to display samplesets you need to: Create and save a sample set using the gfe. 1) select the sample tool 2) click on the points you want. 3) Use the Maps > Samples > Save dialog to save the set. You probably want to do this as the SITE user as ifp.Image is run as that user from the script dialog and all other users will see this sampleset too. Then set the variable DefaultSamples...
-
There is alot of documentation that can be found by poining your browser at: file:///path/to/where/ho/have/gfe/source/GFESuite/doc/onlinehelp/index.html In particular, the ifpImage documentation is at: GFESuite/doc/onlinehelp/ifpIMAGE.html That plus the comments in gfeConfig may make it a bit easier to setup the images you are looking for. NOTE: There is no longer a specific ifpImage program mentioned in the documentation. I moved all the two dozen or so stand along programs into a single one (gfei)....
-
There is alot of documentation that can be found by poining your browser at: file:///path/to/where/ho/have/gfe/source/GFESuite/doc/onlinehelp/index.html In particular, the ifpImage documentation is at: GFESuite/doc/onlinehelp/ifpIMAGE.html That plus the comments in gfeConfig may make it a bit easier to setup the images you are looking for. NOTE: There is no longer a specific ifpImage program mentioned in the documentation. I moved all the two dozen or so stand along programs into a single one (gfei)....
-
I would love to blow away the whole ingest system and create something much more straight forward and easy to deal with. It probably would not even be too hard to do. The major obstacle is finding model data that is: Available online and at no charge Well documented as to what it is. In a reasonably sane data format (grib barely counts) So far, the best I've stumbled across is the NCEP stuff on NOMADS. But even it is less than ideal as it is a MAJOR headache to figure out what cryptic file names...
-
Hmm... The permissions of FWFTable.py in the git repository are 644 (rw-r--r--). But the one you checked out with git has them at 664 (rw-rw-r--). The install script copies many files straight over to the install prefix assuming that git did not mokey with the permissions. I may have to revisit that. How exactly did you checkout the git repository? I wonder if your umask was still 022 when you did the checkout? Or did you use some kinda GUI git wrapper program? In any case, I may have to modify the...
-
I never was an expert on the whole waring generation end of things. But aren't these types the domain of warngen? The configuration of the Hazard weather type is in the ifpServer configuration file. So, if these types are not there they never were. I suppose one could always add them there and then they would be a valid type for Hazards.
-
As you have discovered, you can't use 'gfeConfig' as a configuration file for the ifp.Image program. I have no idea why it was ever set as the default. I changed the default one to 'testIFPImage' which does work. I've also fixed some of the code which broke things running as a script with the new install directory structure. It now runs for me both from a development environment and an installed setup. The line stipple code was a bit broken from the port to c++14. It is now working as well as it...
-
The whole GHG monitor thing (and other bits that use theVTEC active table) may be broken for a while. Much of that code depends upon products being stored in the AWIPS text database. That won't work now for obvoius reasons. There is no way (and won't be) to actually transmit any products. So, the hooks that the gfe has to look at these will not work. Maybe with practice mode (which I've not even looked at yet) it might work. I may be able to simulate it at some point in the future. However, I would...
-
When ifp.ingest runs it does not make any attempt to determine what is the latest model found on nomads right now. Instead it looks at the current time. Then it calculates what is the closest model run for the time right now. It then tries to find any files for the calculated model run and start downloading processing them. So, it may or may not immediatly start downloading files. It just depends on the current time and where we are in the model run cycle. It is not perfect. Again, the idea of ifp.ingest...
1 >
