L3DT Users' Community

I recently have been trying to use the rain plug-in however the results have been a bit odd. Using version 11.11, I get a rainmap that is all "fluffy" and doesn't look right, and the altitude it lists is outrageously high.

This is the command I used: calc.WM.rain <GetMap "HF"> <GetMap "WM"> 2 100 0 -0.5 1

Just wanted to generate a test map. Any combination seems to have the same result though, which is this:





Any thoughts?

Any feedback on this??

Hi Barid,

I apologise for the delay in my reply. As far as I know, the rain plugin works as well (or poorly) as it ever did. It has always been very sensitive to input conditions. Can you please e-mail me the map definition file for your project ([YourProjectName].def.xml) so that I may reproduce your map to test the script under the same conditions? (please send to aaron@bundysoft.com).

Best regards,
Aaron.

Hi Barid,

Thanks for the map definition file. The problem was that in the script the rain depth parameter was zero (not good) and the evaporation rate was positive (doubleplusungood). Together, this combination will cause the water level to continue to rise at every iteration, with the bizarre consequences that you observed. This appears to be my fault, as for some reason I cannot fathom, I had posted exactly these dodgy parameters as examples in the plugin thread (now corrected). I have also updated the plugin documentation page to make it explicit that the rain depth parameter must be positive, and that the evaporation rate must also be positive.

So, in sort, I'd recommend you change your script to:

Code: Select all

calc.WM.rain <GetMap "HF"> <GetMap "WM"> 2 100 1 1 1


This should give you a result that looks more like this:



I apologise for the confusion caused by my poor example script and for the generally poor state of documentation with this plugin.

Best regards,
Aaron.

That didn't fix it for me, still getting the same issue. :/

Hmmmm...perhaps close the 'Rain-avgdepth' map layer, then try the script again?

Still no good. Also I noticed that the saved version was way off, was only 3 levels, bottom half of the image was black, top 2/3 were different shades. But all 3 were insanely high still. I think I've gone through every combination possible now and I keep getting this result.

Hi Barid,

Hmmm again.

Just to be sure there's no weirdness with the script commands, can you please download and run the example script for the plugin.

If that doesn't work, can you check that the datestamp of your version of the 'atRainMaker.zeo' plugin 11 ‎Jan ‎2012? The plugin will be on disk at:

C:\Program Files (x86)\Bundysoft\L3DT [version]\Extensions\atRainMaker.zeo

(assuming Win7/Vista 64-bit; path will be similar for other OS versions)

Best regards,
Aaron.

Same deal. I think I've gone through every combination now with no difference at all. Even did reinstalls.

Hi Barid,

I apologise again for this problem. I think I'll have to compile a special build of the plugin for you that logs extra diagnostic information about the calculation parameters and state variables to see where it's going wrong. I should have it ready within a day or two (sorry for the delay).

Best regards,
Aaron.

Hi Barid,

Does the water map in your project show the same 'fluffy' look? If so, please close the water map and re-calculate it before running the rain calculation. If that doesn't fix the problem, please give this new version of the plugin a try:

http://www.bundysoft.com/L3DT/downloads/plugins/bin/atRainMaker-bin.zip

If that still doesn't fix the problem, please send me the log file after running the calculation. You can get to it from the Windows start menu under 'All programs->Bundysoft->L3DT [version]->L3DT logs'. In that directory, you will find a file called 'log.txt'. With the logfile, I will be able to work out what is going wrong.

Best regards,
Aaron.

Still didn't work, email sent.

I've also tried reinstalling L3DT, and the latest development build.

Hi Barid,

Thank you for the log file. The info allowed me to home in a little more on the fault, and exclude a number of possibilities, but it's still not exactly clear what has gone wrong. With the changes I had made I can no-longer reproduce the fault for any choice of settings, which is frustrating the debugging no end.

If I may beg a little more of your patience, may I ask you to please download another update to the plugin (same link as before), run it as per usual, and send me the log file again? This updated version will spam the log with lots of internal working data from within the flooding simulation, which should further narrow down which of the intermediate stages is causing the problem.

There should be no need to uninstall anything; just copy the new plugin over the old one.

Thanks again for your help and patience so far in tracking down this fault.

Best regards,
Aaron.

Sent off.

Hi Barid,

Thank you for the log. It showed that the results at the conclusion of the first iteration are wrong, even though the calculations at each individual pixel are OK. However, for speed reasons I only logged results from 1 pixel per 16x16 block, so perhaps the calculation is going off the rails for some un-logged pixels. I have changed the plugin to detect and report invalid results on individual pixels, and dump the full set of relevant data for those pixels to show why the calculation went wrong.

It's still a bit of a mystery as to why this bug is entirely reproducible on your system and not reproducible on my test systems. Perhaps the bug is something like using an uninitialised variable, which on my systems may just happen to be 0, and on yours may be something else. I've now tidied up the algorithm to make sure this is not happening, but since I can't seem to trigger the fault, I can't test whether I've fixed it.

Anyway, the updated plugin is here. The changes I've made may fix the fault, and if not, they should provide enough information to track don the bug.

Please let me know how it goes.

Best regards,
Aaron.