Due to SPAM attacks, new members must be approved before posting.  Please email when registering and your account will be approved.

Main Menu

Error using Count button

Started by kfreeman, April 01, 2010, 07:49:30 AM

Previous topic - Next topic


I am trying to run SLAMM 6, but cannot get to enter Map Attributes. All the txt files are the same dimensions in the same directory with 4GB memory in my computer.  5 meter cell size, so it ends up being ~30 million cells.  First, I entered the file names and site parameters,  and when I tried to enter Map Attributes I got a range check error.  I looked up the forum advice for that, exited the model and tried again using the ignore high elevations and water.  The count was about 23 million cells and ~1.3GB memory usage.  But, in Map Attributes I got a Error creating map in memory, write map to disk instead?  Clicking Yes or No gave me a Range Check error. Now, however, when I try it again, the Count button will only work on "Track all cells".  If I try the other options for Count button, I get the following error: "Must Include SLAMM Code (NWI) Data File".  Of course, the file is there, and is correctly set up as far as I can tell.  Using "Track all cells", I move on and then I then get the Range Check/Error creating Map problem.  I have tried various things:  renaming, moving files, different computer.  What should I try next?   

Jonathan S. Clough

Yes, as noted in another thread I'm going to be playing with the count button and memory counting procedures in general to bullet proof that.   I think I already fixed the "must include SLAMM code (NWI)" problem though I will look at that again to be certain.

Other than that, I'm afraid you're just running out of memory.  

Each application in 32-bit Windows only has 2GB of memory to work with no matter how many GB are installed on your machine.  (The one time I tried to increase that application-specific limit to 3GB by modifying the BOOT.INI, that rendered my machine non-bootable so I did not continue with that line of inquiry.)  Furthermore, only 3GB total are usually available due to the operating system's need for addressing space.

So your site has a 1.3GB "footprint" but is still running out of memory.  

The problem partially stems from the array that we use to keep track of whether a cell is being tracked or not and where it is being tracked.  To relieve memory
congestion a few steps were taken recently:

1. SLAMM memory maps are no longer set up in contiguous memory but instead split into many pieces.
2. SLAMM memory maps can be optimized so that blank cells, high-elevation cells, and open water may be ignored.

However, a single array was utilized to track, for each cell, whether it is ignored or not and where in memory the data for that cell is located.  A single array requires contiguous memory and this array is so large for some sites that it tends to cause the crash.  So apparently a third memory-optimization step is going to be to split up the memory tracking array
into pieces so it fits into memory more gracefully.  I'm not sure when I'm going to get a chance to work on that, unfortunately; my priority is to work on a 64-bit implementation.

So you can try to run your computer as clean as possible (remove as many programs from the memory and reboot so that free memory is more likely to be contiguous) and keep your fingers crossed.

The other possibility is to run it on a flash drive and select the "save to disk" option.  That should work, though will be slow...  You will need to move all your simulation files to the flash drive and SLAMM will save files to disk there.

Otherwise, break your site into smaller pieces or keep your fingers crossed for the 64-bit implementation...

Good luck

Jonathan S. Clough

An update on this.  The 64 bit implementation is both nearly complete and also not going well. 

After many days of work, I have a 64-bit version of SLAMM that will compile and load projects (using Lazarus under FreePascal) but the software is not stable and the Lazarus 64-bit debugger is apparently not working properly at this time either.  Lazarus has proven an unstable platform to some degree and the software regularly produces cryptic error messages that do not provide the reason for, nor the location of the software crash.  So I'm putting 64-bit SLAMM aside for the moment.  It is a painful decision given all the time spent trying to get this to work.  If anyone else has expertise in Lazarus and wants to try to move forward with this I'll be happy to send you my latest code-base and a list of known issues that need to be resolved before 64-bit becomes stable and useful.

In the meantime, though, I had a recent realization.  There is no reason that 64-bit operating systems should not allow 32-bit software to use a full 4GB or memory.  After doing some research I realized that I just need to send a signal to the compiler to allow this to occur.  A test program then allocated over 3GB of memory in a 64-bit OS.  So, even though 64-bit SLAMM is not imminent, a compiled 32 bit version that allows you to double your memory utilization under a high-memory 64-bit OS is imminently pending.  If anybody needs this immediately (before the next beta release) due to memory problems, please let me know.

Thanks -- Jonathan