I just stumbled upon a very, very weird bug. Not sure if it should be posted in Base Wind, Base Fire, or in the Library-Metadata repo.
By integrating Base Wind 3.0 in my simulations that already used Base Fire 4.0, everything started to break at the first time step when Base Fire tries to log a fire event. The error is :
Running Base Fire ...
Processing landscape for Fire events ...
Internal error occurred within the program:
'column' argument cannot be null.
Parameter name: column
Stack trace:
at System.Data.DataRow.CheckColumn(DataColumn column)
at System.Data.DataRow.set_Item(DataColumn column, Object value)
at Landis.Library.Metadata.DataTableExtensions.AddDataObject(DataTable tbl, Object dataObject)
at Landis.Library.Metadata.DataTableExtensions.AppendDataObjects(DataTable tbl, IEnumerable dataObjects)
at Landis.Extension.BaseFire.PlugIn.LogEvent(Int32 currentTime, Event FireEvent)
at Landis.Extension.BaseFire.PlugIn.Run()
at Landis.Model.Run(String scenarioPath, IUserInterface ui)
at Landis.App.Main(String[] args) in /mnt/d/OneDrive -UQAM/OneDrive - UQAM/1 - Projets/These - Article du module FRS/1 - Module de route/3 - LANDIS-II-LINUX/Tool-Console/src/App.cs:line 99
I tried to understand where it came from and try to replicate it on some test files (the test files in the Base Fire repo) to make testing quicker (my landscape takes a long time to load). Surprisingly, I was unable to replicate the problem with the test files.
So I kept trying different variations to see where the problem layed :
If Base Wind was disabled and Base Fire enabled, everything worked.
If Base Fire was disabled and Base Wind was enabled, everything worked.
If I was used another succession extension, the problem remained.
If I disabled any other extensions (e.g. outputs of other disturbances), the problem remained.
If I used a different random seed, the problem remained.
So it seems like the issue only triggered when Base Wind and Base Fire were used together...but not in the testing files. Was the landscape the issue ?
But finally, with a lot of tweaking, I was able to reproduce the bug on test files. Strangely, it was...the ecoregions/fire regions ! It looks like if the fire regions defined in the Base Fire parameter file are not the same as the ecoregions mentionned in the Base Wind parameter files, the problem occurs.
To prove my point, you can download the test files here. In the NotSameRegionsInWindAndFire-ErrorColumns folder, the error happens, and the fire regions mentioned in base-fire_SetUp_s1e1.txt (ZONE5 and ZONE7) are not the same as the ecoregions mentioned in base-wind_SetUp_s1e1.txt (eco1 and eco2). If you launch the scenario, the problem occurs.
On the contrary, the files in SameRegionsInWindAndFire-Works are the original testing files, with base-fire_SetUp_s1e1.txt and base-wind_SetUp_s1e1.txt both mentioning eco1 and eco2 as fire regions/ecoregions. If you launch the scenario, the problem doesn't occur.
Digging into the code, my suspicion is that in the AddDataObject function of the Library-Metadata, a confusion is made between the two extension that results in the wrong columns or the wrong table being used to save the log of the fire event to the event log. But there are so many objects interacting and the initialization of metadata is so complex that I have no idea where the problem lays.
So...here it is. I hope that this will help to solve the issue. Now that it's isolated in some test files, I hope this can help speed up the solving. I hope it can be solved, because we can't use Base Wind until it is (since our ecoregions are very different from our fire regions).
Hello !
I just stumbled upon a very, very weird bug. Not sure if it should be posted in Base Wind, Base Fire, or in the Library-Metadata repo.
By integrating Base Wind 3.0 in my simulations that already used Base Fire 4.0, everything started to break at the first time step when Base Fire tries to log a fire event. The error is :
I tried to understand where it came from and try to replicate it on some test files (the test files in the Base Fire repo) to make testing quicker (my landscape takes a long time to load). Surprisingly, I was unable to replicate the problem with the test files.
So I kept trying different variations to see where the problem layed :
So it seems like the issue only triggered when Base Wind and Base Fire were used together...but not in the testing files. Was the landscape the issue ?
But finally, with a lot of tweaking, I was able to reproduce the bug on test files. Strangely, it was...the ecoregions/fire regions ! It looks like if the fire regions defined in the Base Fire parameter file are not the same as the ecoregions mentionned in the Base Wind parameter files, the problem occurs.
To prove my point, you can download the test files here. In the
NotSameRegionsInWindAndFire-ErrorColumns
folder, the error happens, and the fire regions mentioned inbase-fire_SetUp_s1e1.txt
(ZONE5
andZONE7
) are not the same as the ecoregions mentioned inbase-wind_SetUp_s1e1.txt
(eco1
andeco2
). If you launch the scenario, the problem occurs. On the contrary, the files inSameRegionsInWindAndFire-Works
are the original testing files, withbase-fire_SetUp_s1e1.txt
andbase-wind_SetUp_s1e1.txt
both mentioningeco1
andeco2
as fire regions/ecoregions. If you launch the scenario, the problem doesn't occur.Digging into the code, my suspicion is that in the AddDataObject function of the Library-Metadata, a confusion is made between the two extension that results in the wrong columns or the wrong table being used to save the log of the fire event to the event log. But there are so many objects interacting and the initialization of metadata is so complex that I have no idea where the problem lays.
So...here it is. I hope that this will help to solve the issue. Now that it's isolated in some test files, I hope this can help speed up the solving. I hope it can be solved, because we can't use Base Wind until it is (since our ecoregions are very different from our fire regions).