Custom Query (210 matches)
Results (67 - 69 of 210)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#155 | fixed | Minor modifications in packaging of FPv9.3.1c for CTBTO use | donaldjmorton | |
Description |
This is a brief statement of some minor changes made to FPv9.3.1. No action is necessary |
|||
#161 | fixed | Add a dimensions check to FPv9.3.1 when reading preprocessed files | donaldjmorton | |
Description |
Currently, the output and input of preprocessed met files (referred to as "fp files") is accomplished with raw binary dumps of scalars and arrays - this is done for efficiency. However, this requires that the GRIB2FLEXPART that generated the fp files is compiled with exactly the same dimensions as the FLEXPART that reads the fp files. This is not unreasonable, especially since the two binaries are generated with a single Makefile. However, in one case, a user unknowingly generated fp files with the z-dimension set to 138, and then read them with a FLEXPART where the z-dimension was 140. In this case, the program ran for a quite a while, then bombed, wasting a lot of time. Therefore, I'm going to implement a check in FLEXPART so that when it reads an fp file for input, it will insure that the dimensions written into the fp file are the same as the dimension with with FLEXPART was compiled. If this is not the case, FLEXPART will simply abort with an informative message. For anybody who reads this, please note that at this point, we're still trying to determine whether the "raw binary dump" is the best format for the fp files, or if we should switch to something like NetCDF4. |
|||
#163 | fixed | FPv9.3.1 - changes related to CTBTO environment and grib2flexpart | donaldjmorton | |
Description |
Several changes have been made by myself and Gerald Klinkl (CTBTO)
This ticket may be closed by anybody with such authorization. |