spatialmodel / inmap Goto Github PK

Currently, some values may be blank in output shapefiles because value size + precision can exceed the variable length limit of shapefiles. This issue could be fixed by reducing the precision of large output values.

We should include more recent data in the next release.

This issue is the same as the previously submitted one.

What are you trying to do?

I am trying to run inmap sr predict with mortality-related output variables.

What did you do?

I used inmap run and inmap sr predict. First, I tried each using our own input data files and config file. Second, I tried each using the github repo data at the path cmd/inmap/. I used exampleConfig.toml, the provided test data at the default paths, and the only thing I changed in the config file was the SR.OutputFile path to be the path to the IRSM matrix downloaded from Zenodo linked here.

Here are the results for the four attempts to run with mortality output:

1. Using inmap run with our data/config file along with some example data needed as input to inmap run. This did not throw an error and it outputted the target mortality data. Success
2. Using inmap sr predict with our data/config file. This threw the error message "inmap: undefined variable name 'AllCause'" and terminated.
3. Using inmap run with only example data/config files from the github. This did not throw an error and it outputted the target mortality data. Success
4. Using inmap sr predict with the same example data/config files. This threw the same error of "inmap: undefined variable name 'AllCause'" and terminated.

If I remove the mortality-related output variables then inmap sr predict works, but we don't get these mortality outputs that we want. Other things I tried are: playing with the capitalization of AllCause to allcause in the config file and moving the Mortality Rate and Census related fields in the config file to the top.

What did you expect to happen?

We expected inmap sr predict to successfully run and compute all the output variables, but when we use AllCause in the formulas for output variables, the previously mentioned error message is thrown. It is the same error message every time.

What actually happened?

With the exact same setup (except that inmap sr predict uses the IRSM file and inmap run does not), inmap run works correctly while inmap sr predict throws the error "inmap: undefined variable name 'AllCause'" and terminates.

What version of Go and InMAP are you using?

Using inMAP version: inmap-v1.9.2-linux-amd64
We haven't used Go at all. To run inmap we use the commands: ./inmap run steady --config="configfile.toml" and ./inmap sr predict --config="configfile.toml"

Does this issue reproduce with the current master?

Yes

So if different computer systems or future versions of the model take longer to initialize, it may cause an error.

These variables should either have emissions values assigned from them or not be written out. I would lean towards not writing them out.

This happens when an output variable is defined in one line of the configuration file and then used when creating another variable. The TOML file parser transforms the first variable name to lowercase so that it can't be used as defined in other variables.

... so that users can send a log file with their question even if they did not save the terminal output to a file.

What are you trying to do?

I am trying to model health impacts from an emissions scenario by including a mortality shapefile for all states in the US.

What did you do?

I had formated the config file as specified here: https://github.com/spatialmodel/inmap/blob/master/cmd/inmap/configExample.toml#L145

and my morality shapefiles has headings labeled allcause

What did you expect to happen?

I expected it to be able to read the morality shapefile and produce annual deaths.

What actually happened?

It doesn't appear that the mortality shapefile is being read in. An error occurs stating unknown variable "allcause"

What version of Go and InMAP are you using?

Does this issue reproduce with the current master?

Notes:

• https://github.com/cavaliercoder/grab

Test coverage decreased after adding the emissions processors.

The order of the variables returned from the marginalPartitioning function in preproc.go does not match the order of variables in the function calls from lines 221-246. This is in the master branch.

This will allow people to use the SR matrix without doing a lot of coding. The command signature could be

InMAP SR read

with configuration options for input and output shapefile.

In the integration time step calculation here, the Dx, Dy, and Dz are assumed to be in metres, which are not necessarily the native units of the spatial projection (e.g., for my output using GEOS-Chem, the units here are degrees).

A 'quick fix' for those using degrees is to simply multiply the Dx, Dy, and Dz by 100,000. This may cause numerical stability problems at latitudes where 1 degree is significantly less than 100km; so a smaller multiplier would be better if these latitudes are within the spatial domain (in my case they are).

A long-term solution would have the time step equation change accordingly, taking into account the native resolution of the output, or perhaps have it be specified by the user.

It would be useful to have a preprocessor for the CMAQ model: https://www.epa.gov/cmaq

This would make configuration easier and reduce user errors. Some things that should be automatic:

• Lower-left corner of input data domain
• Grid projection
• input data grid cell size

With 96km horizontal grid cells sizes, the pollutant concentrations go to infinity.

InMAP produces unrealistic plume rises in some cases. The issue is described in details here: BAAQMD/InMAP-SFAB#13

The Readme only has directions to define the evaldata environment variable in the section that describes how to compile InMAP. Won't users need to define the evaldata environment variable regardless of whether they compile? Alternatively they could just replace "${evaldata}" in the config file with the absolute path for the evaldata folder. Either way, we may want to clarify this step.

Some people find it easier to work with raster data rather than vector data. InMAP could add an option to support this in the output

Currently, the spatial projection for the output file is set as a constant. This will cause a problem for versions of the model that do not use that specific projection.