Closed Jepeixoto closed 10 months ago
Hi @Jepeixoto, thank you for getting in touch. Could you please share with us the settings .xml file that you used to model the basin domain area and the setting .xml file that you used to model the subcatchment? It is important to better understand your set-up in order to investigate the problem. Thank you in advance for your collaboration!
Hi @StefaniaGrimaldi, thanks for the feedback.
Following are the settings.xml used to model the basin domain area and for the subcatchment. I used the same settings.xml, just modified the maskmap line. Also follow the dis_run.tss files generated with the basin domain area and with the subcatchment, to see the difference in the discharge result. Attached files are in .csv format just to insert here, but I'm running them in the template in .xml format. Our maps are in geographic coordinate system (latitude/longitude), DATUM WGS 84. Thank you for your help! run_lat_lon_domain.csv run_lat_lon_subcatchment.csv dis_run_domain.csv dis_run_subcatchment.csv
Hi @Jepeixoto,
thank you for sharing the settings and the results. After looking at your files, I think that we can investigate two options:
1) I see that areamodel_PortoVelho.nc is the mask map of the subcatchment and areamodel.nc is the mask map of the basin domain. The settings file run_lat_lon_subcatchment has the option INFLOW OFF. Does this mean the the areamodel_PortoVelho.nc includes only headcatchments? I noticed in the settings file the map inflow_new3.map, which indicates the location of the inflow points, and the file inflow.tss, with the discharge hydrographs. However, since the option inflow is off, neither inflow_new3.map nor inflow.tss are used. This is correct in the case that areamodel_PortoVelho.nc includes only headcatchments. The handling of inflow points did not change in Lisflood v4.0.0 compared to the previous versions.
2) In order to maximize the consistency between the modelling of the basin domain and of the subcatchments, we recommend A) to keep the option groundwaterSmooth OFF, and (in case the option wateruse is ON) to B) prepare the water region map following the guidelines explained here Important techical note for the adequate definition of the water regions https://ec-jrc.github.io/lisflood-model/2_18_stdLISFLOOD_water-use/ . We provide this utility https://github.com/ec-jrc/lisflood-utilities/tree/master/src/lisfloodutilities/waterregions to help the users build their own water regions map. Recommendations A and B held also for the previous versions of LISFLOOD, nevertheless, is some specific catchments, with specific soil types and water abstraction maps, they might become more important with version 4.0.0. This is due to the new pixel-wise handling of the soil and to the new protocol to model water abstraction, a summary of the changes is available here https://github.com/ec-jrc/lisflood-code#notes-for-release-400
I hope my answer helps to make some progress in order to solve the issue, please let me know your thoughts, kind regards, Stefania
Thank you for your help. We checked the two suggested options. The areamodel_PortoVelho.nc is a point downstream of the basin, I included the inflow points correctly and option INFLOW ON, but the result is still erroneous when executing for the subcatchment. Sorry, I didn't configure the previous settings correctly when I sent you. We believe that the problem is in relation to the outlet map. Because, when running for subcatchment using the outlets.nc map, the discharge is inconsistency. However, when we enter the coordinates of the gauge locations, using the areamodel of the sub-basin, the result is consistent. Attached is the configured settings and the dis.tss file for this test. We think if there are any details that we don't know when running version v4.0.0 with the outlets map, when running for a sub-basin. Question: when running for subcatchment, should you have a specific outlets map for the subcatchment? We noticed that in the test folder LF_lat_lon_UseCase there is more than one map of outlets. Please, if you can help us in the construction of this reasoning. Thank you, Jerusa. run_lat_lon_gauges_PV.csv dis_run_PV_gauges_latlon.csv
Hi @Jepeixoto,
thank you for the update.
If I understood your message correctly, switching on the inflow option allowed to solve the problem of the very low discharge values in the subcatchment domain. However, there are problems when reading the outlet positions from the map (but everything works when you write the coordinates of the outlets in the xml settings file).
May I ask you to share with me some further piece of information? It is important for me to better understand the issue with the map.
I see that in the settings used to model the full domain, you have the maps areamodel.nc, outlets_World.nc; while the subcatchment uses areamodel_PortoVelho. Could you please share those 3 maps? I noticed that you updated the map with the inflow points, now called InflowPoints_PV_6.nc. I assume that you used the chanq.tss results of the full model domain to create QinTs_PV_8_corrig.txt. Could you please also share those 2 files?
Finally, I noticed that the option wateruseRegion is now off. It is recommended to keep the option on, if you do not feel comfortable to use the utility before finishing these tests, I will be happy to take a look at your existing map and provide a feedback.
Thank you for your collaboration, kind regards, Stefania
Hi Stefania, Thanks for your return. The problem of very low discharge values in the subcatchment domain continues when using the inflow option. Correct, when we write the coordinates of the outlets in the xml settings file, instead of inserting the outlets map, the discharge values for the sub-basin is correct.
What we are finding strange is that in version 2.10.3 we used the same maps and the discharge values for subcatchment and basin domain were the same, without problems. But in version 4.0.0 the result for subcatchment is wrong.
Correct, the chanq.tss results used to create the QinTs_PV_8_correg.txt are from the upstream station simulation, for the time of interest.
I will check the utility for the wateruseRegion option. I would like to send you the requested files, but it does not allow you to insert files in netcdf format here. Can I email the files, please?
Thank you very much for your availability to help us. kind regards, Jerusa.
Hi @Jepeixoto,
thank you for the answer and the willingness to share the files.
Here is my email: stefania.grimaldi@ec.europa.eu
To clarify, I read in your message that "when you write the coordinates of the outlets in the xml settings file, instead of inserting the outlets map, the discharge values for the sub-basin is correct". Could you please confirm? If you confirm the statement above, it means that the computations within LISFLOOD are correct. Since area_PortoVelho is not a headcatchment, the option inflow must be on (and now this is correct).
The remaining problem is then limited to the usage of the outlet map in order to print the output file for the subcatchment domain. The outlet map is only used to identify the pixels for which we want to save the discharge data, and it is not used within the computations. I am keen to understand why there is a problem in printing the results when using the map. Could you please also share with me the output that you obtain when using the map?
Thank you for the collaboration, kind regards, Stefania
Hi Stefania, Thank you for the availability.
I confirm: "when you write the coordinates of the outlets in the xml settings file, instead of inserting the outlets map, the discharge values for the sub-basin is correct". "Could you please confirm?": Yes.
Your reasoning is good: "The remaining problem is then limited to the usage of the outlet map for the subcatchment domain in order to print the output file".
I will separate all the maps and requested files for you to check and send with an explication of the files to your email, ok.
Thank you for the collaboration. kind regards, Jerusa.
Hello community! I have a problem with version 4.0.0 when running for the basin domain area and for a subcatchment. When I run to the basin domain, the channel discharge results in the dis_run.tss file are consistent, but when running for a subcatchment the results are very different, the channel discharge reduce drastically. We have already used these same maps in previous versions, 2.10.3 and 3.0.0, and the channel discharge results for the domain area and subcatchment were equivalent between both areas. So, I ask for help in this problem, if there was any change in version 4.0.0 to run for subcatchment.