I added this for runs where a multiband geotiff output is specified (dust simulations) to reduce memory. We should probably do this for wx model runs (the only other case where ninjas.size() > 1) too, but there is some issue with deleting the last ninja of those runs.

thredds.csv would get installed into an area that is read only. We need a place (${HOME}/.windninja/...) to put writeable copies, and perhaps other settings.

DEM downloads with no data were not getting filled in the cli. It was a typo in the flag to check if we had downloaded the file. Fixed in 172be7e

This will allow update without recompile. It wouldn't be much work, and could be binary or human readable (sqlite or xml). SQLite would be easier to implement, CPLXML* could handle xml parsing. The file could be used as a default override for hardcoded values, or user supplied.

Move pertinent wiki pages from redmine to github.

Might be handy to be able to set this as a config option in the gui for debugging purposes.

Use better #defines, and write major, minor, patch:

#define WINDNINJA_VERSION_MAJOR        2
#define WINDNINJA_VERSION_MINOR        5
#define WINDNINJA_VERSION_PATCH        0
#define WINDNINJA_VERSION_STRING       "2.5.0" //from above defines.
#define WINDNINJA_GIT_REVISION             "3fc1dfd955c2d6220b1434ed3d8487515905f671"

change the filename to windninja_version.h

Should disallow if thats the case. Simple check added in gdal_fetch: 7b710f3

ArcView is no longer supported on modern OS's. It can be removied.

Point initialization with stability on and diurnal on doesn't seem to converge for the mackay test case. It appears the simulation starts to bounce between negative and positive diffs (difference between measured and simulated values at points).

Using a WindNinja mesh instead of a blockMesh should speed up moveDynamicMesh since WN meshing is quick and generates a starting mesh that is already conformed to the terrain.

The progress should jump to 100% done no matter how far along the last run sets the value.

2.4.1 is at 3059c86, need to find 2.4.0

Too verbose, not robust, and leaks memory.

Seems to be an issue in the solver. Mesh builds, but solver doesn't run.

A testing protocol should be developed before releases. Basically a list of human-run tests with feedback. Run all weather models, all data download, etc. As tests get merged into the autotesting suite, we can discard them. We'll all have to work on the testing, but Jason gives the last OK.

The boost time zone data base and the tzinfo generated shapefile aren't completely in sync. Unfortuneately, I don't think there is an obvious fix. Boost doesn't make a spatial file, and the available shapefile is based on tzinfo. Generating a boost compatible csv from the tzinfo data seems like a possible alternative. This stems from #25 where the zone from the map had an 'extra' 'Argentina' in the name, and the boost spec did not.

The NOMADS writer fails to copy forecast data to drives other than C:\ (or possibly the driver WindNinja is installed).

The cli throws an exception if no args are provided, should show help.

We need to add a progress callback that allows for cancelling. We can use GDALProgressFunc() and kin. Currently the DEM downloader window can be cancelled, but it just leaves the process running.

The simulation blows up after pushing the solve button. Info:
Windows 64-bit release version
mackay.tif
trees
coarse
America/Boise
diurnal off
stability off
wx model initialization
NOMADS-GFS-GLOBAL-0.25-DEG
6 hrs download
google earth checked
threads = 8

When it blows up, "Generating mesh..." is the last thing written in the console.

• 2.0.0
• 2.0.1
• 2.0.2
• 2.0.3
• 2.1.0
• 2.1.1
• 2.1.2
• 2.1.3
• 2.2.0
• 2.3.0
• 2.4.0
• 2.4.1
• 2.5.0

Boost 1.46.1
curl 7.40.0
gdal 1.11.1
geos 3.4.2
netcdf 4.3.2
proj 4.8.0
Qt 4.8.5
zlib 1.2.8

Do we need this output in the GUI? I think we can remove this, or conditionally compile it. We just have to explain that users shouldn't use it.

It would be very useful to have an option in the GUI to write a config file using the current GUI settings. This would be especially useful to help us replicate problems users are having. Also, this could be the start of a File->Save As type feature to save run settings.

It would be useful to have a command line tool to convert xyz output from OpenFOAM to other formats (kmz, raster).

WindNinja blows up when you do multiple domain average runs from the GUI. This occurs when you hit solve. On Windows.

If any run requiring an time zone is requested and the time zone could not be automatically set, issue a warning. Do nothing if the user has already selected a zone.

This is definitely somewhat trivial but while creating server-side and client UI for the output, consistency in the naming pattern makes coding a little easier and less error prone to all the different flavors. I haven't checked all the models or other output types but here's what we see:

FIRST: Ninja outputs vs Wx outputs

Ninja output files are named in the pattern:
{surface file}{date}{time}_{grid?}

Wx model output files are named in the pattern:
{model name}-{date}_{time}

Finding date/time in both requires two different patterns. The model names have underscores in them so that presents a problem for using the underscore as the consistent separator... maybe dot? not sure how the other platforms like dots inside the files names.

SECOND: Wx model name prefixes
NOMADS and UCAR models write their wx shapefile outputs differently as well:
NOMADS: hrrr_conus-02-17-2015_2000
UCAR: UCAR-NAM-CONUS-12-KM-02-17-2015_1700

In this case it would be nice to regurgitate the entire model name consistently.

Nit-picky stuff but these are some of the things we bump into creating workflows downstream of the output.

Imported from svn:

On small DEM files, this can happen causing an invalid read. See r3251, r3252 and r3253 for fixes and assertions in trunk/branches/2.4

Currently set to 200. This is overkill for many cases. Need to define some stopping criteria. The number of required iterations may also decrease if we start with a better base mesh or speed up the diffusivity model used by MDM.

This is for NinjaFoam, initial implementation in f7e5932. Needs testing

Hopefully make maintenance way easier, also may coincide with the C API.

0c1b7be broke ninjafoam. setSize() needs to allocate ninjafoams if the momentum solver is picked.

NOMADS now has GFS 1.0, 0.5 and 0.25 models in the 'Parallel Models' section here:

http://nomads.ncep.noaa.gov/

We should check and see if the 0.25 is available for replacing the current 0.5deg model.

Need to add something like prepareOutput() in ninjafoam for output grid clipping and setting output units as requested.

Appears to possibly be a McAfee Gateway Server issue where the server is removing the partial content header from the request.

Possible help:

https://community.mcafee.com/docs/DOC-3348
and
https://community.mcafee.com/thread/60214?tstart=0

Contact for reporter:
Carl Cerniglia - NOAA Federal carl dot cerniglia at noaa dot gov
Richard Leupold - NOAA Federal richard dot leupold at noaa dot gov

Right now we only use 2nd order discretization for div((phi,U). We should look into using 2nd order for the other divergence terms, but need to make sure the numerical scheme is stable.

We need to implement start, stop, stride as times and time deltas. Currently, we just use an end time. We go back to the last available forecast run, and do each time step until we are told to stop. So if the user asks for 6 hours of forecast from NAM, and the last run was 3 hours ago, they'd get 9 runs, when They'd probably expect 6. Additionally, we should allow for stride setting, so we can use higher spatial res models for fewer runs (eg HRRR). This is semi-implemented in the NOMADS fetcher, at least exposed in the NomadsFetch routine, but not tested, nor implemented in the actual interface. This will cut down on runs if we ever initialize OpenFOAM runs with a wx model.

Design and implement a case file.

• Case files will be optional.
• Case files will be immutable.
• Users can load an existing file but not save back to it, unless they overwrite the old.
• Output grids will be saved to the file.

We should just look for variables we can use. Shouldn't be too difficult

This problem occurred in Sardinia on computers that were using a proxy server on the LAN settings. This setup required every program that used the internet to authenticate to allow internet access. So, for example, each time Internet Explorer or Google Earth was started, a pop up box opened asking for the username and password. This was required EACH TIME the program was opened. When WindNinja was run, this pop up box did not open, and so the internet features of WindNinja didn't work (DEM grabber, some GDAL features, wx model downloads).
To test possible fixes, we can send installers to Michele Salis in Sardinia, he can test this every Thursday during his class.

The output writing was not thread safe, fixed in 2e12c55 and backported in cb5c69f, ticket for documentation.

When trying to run WindNinja 2.4.0 with NDFD downloaded data for hour values ranging from 120-168 (5-7 days out), the program cannot solve. I'm quite certain the issue is with this particular parameter, as I have tested varying locations and DEM resolutions.

Add NOMADS as a forecast source.

landfire:

http://landfire.cr.usgs.gov/arcgis/services/Landfire/US_130/MapServer/WCSServer?request=GetCapabilities&service=WCS

http://landfire.cr.usgs.gov/arcgis/rest/services/Landfire/

Update the cmake stuff to write the version files when make version is run, and make it a prerequisite for make package.

Right now the default is (somewhat arbitrarily) set to 2000. Should come up with some criteria for determining an acceptable target number.

Right now we just set a constant z0 and Rd. Look at SOWFA code to see how we might use spatially varying parameters instead.