Open mrieser opened 5 years ago
Originally, we had enums here. Joe Malloy at some point changed the code such that all emissions that are registered in the input file are automatically used to generate corresponding emissions events. In consequence, the whole thing is no longer typed.
We have other places in MATSim where we moved from types to strings. However, we always then register these strings in the config file (activity types, modes, ...). This is not the case here.
Not sure how to proceed. At VSP, it seems that stuff was more or less patched together so that it works again, but without a clean design decision. Independent from this, clearly material in matsim should work and be secured by tets.
From a VIA perspective, I would say that the config approach would not help you; on the other hand, you could just do what Joe did and aggregate whatever you find in the events file. Maybe the events analyzer that you are looking at here should in fact just do the same?
Note that I am just telling history. I would be happy to clarify this.
It's for once unrelated to Via at the moment. I'm really just trying to use the emissions contrib within a MATSim scenario.
Based on the StackTrace, it looks as if there are still parts of the Enum in use when using the events-reader, which causes the problem.
@joemolloy do you have an idea how to fix this?
I find it especially strange that I have for the same event types (e.g. coldEmissionEvents) both cases, NOx
and NOX
, in different events. I would have assumed that all events of one type get created the same way, but that does not seem to be the case.
@mrieser
I can first run
RunEmissionsOfflineExample
, which produces an emissions-events file.
I have tried to get as far as you, but keep getting an error
com.google.common.util.concurrent.ExecutionError: com.google.common.util.concurrent.ExecutionError: java.lang.NoClassDefFoundError: HbefaVehicleCategory
Did you not run into that problem? Not even the tests on my side run successfully.
I just looked at it; this is probably caused by @billyc and/or @Janekdererste . I wrote a separate email since it seems that they are not reading this issue here. (In fact, maybe it should move to jira, since it is not a code-examples problem.)
I've introduced the Pollutant Enum, because I programmed along an exsisting analysis from benjamins playground which hat its own Pollutant enums.
I can replace the Pollutant enum by simple String keys. Then, pollution would simply be stored as a String, Double pair.
Thanks for looking into it. A string key would probably help reading the data in, but I'm still confused why I see NOX
and NOx
in the events. For me, they should be the same.
@mrieser the only place where I see the difference (or at least NOx hard-coded) is in org.matsim.contrib.emissions.events.TestColdEmissionEventImpl
(line 52)
private final Set<String> coldPollutants = new HashSet<>(Arrays.asList("CO", "FC", "HC", "NMHC", "NOx", "NO2","PM"));
@mrieser , do you have NOx or NOX in your hbefa input files?
@joemolloy : I've taken the example files from the repository (e.g. https://raw.githubusercontent.com/matsim-org/matsim/master/contribs/emissions/test/input/org/matsim/contrib/emissions/sample_EFA_ColdStart_vehcat_2005average.txt) which uses NOx.
@JWJoubert : Yes, I've found that place as well. Still, making it flexible seems not to work together with the Enum still being used while being parsed. And all my input files seem to use NOx
, which does not explain why I get sometimes NOX
in the events.
Will have a closer look as well when I find time.
I'm trying out the emissions contrib, and there seems to be a problem.
I can first run
RunEmissionsOfflineExample
, which produces an emissions-events file. I then try to useEmissionGridAnalyzer
which takes as input this emissions-events file. When running the analyzer, I get the following exception:Looking at the emissions-events file, I see that sometimes
NOx
is used as attribute name, and sometimesNOX
(note the different cases ofX
). If I change all toNOX
, the analyzer can process the file. So there seem to be at least two sources that create the emission-events, one correctly usingNOX
, and the other using the un-parsableNOx
as attribute name.This basically makes the emission-events file unreadable by standard code.