Limit for allocations

Hi, I am using the Rootfinding Isolate function to solve a system of polynomial equations. It works very well most of the time but ocasionally I get the following error message:

Error, (in RootFinding:-Isolate) Limit for allocations (1-->1000): in update_all_garbages !

Does anyone know what this means? - I assume it has something to do with the memory allocation.

Any ideas on how to prevent this error?

Thanks

Steve

acer's picture

submit

This looks like an internal error message that is not supposed to surface. You might consider submitting a report about it.

The author of the code would probably like to see an example that produced the error reliably (if you have such).

I could not find such an error statement in the RootFinding:-Isolate command at the Maple library level. But it does exist in the compiled shared library libfgbuni.so. And the ?Isolate help-page does not mention it.

acer

clso's picture

Example?

I agree with acer.  An example reproducing the error is appreciated.

Clare So
Developer, Math Software
Maplesoft

gkokovidis's picture

memory

 It is mentioned under Memory Allocation Erors.  Bring up the help page using:

?allocations

You can alter the depth level using kernelopts.  For more help type:

?kernelopts

Look at the datalimit option:

datalimit            integer   The total amount of heap memory in               
                           kibibytes that Maple may consume. Maple          
                           aborts if this limit is exceeded.                
                           If the value is 0 or it is not given the         
                           current limit is returned. Limits may            
                           be raised or lowered. Maple limits               
                           may not be raised above system imposed           
                           hard limits. This option is not                  
                           supported on all platforms.                      
                           Values passed for this option can be             
                           given with a Unit of information.       

 

 Hope this is helpful.

Regards,
Georgios Kokovidis
Dräger Medical


acer's picture

I don't see that

I don't see any reason to believe that this is related to kernelopts(datalimit), the parent shell's limits, or similar.

It might in fact be coded right into the (external) shared library called by RootFinding:-Isolate, and be a separate management mechanism.

The OP might raise limits in the parent shell by using (say) ulimit, and then in Maple itself with kernelopts(), and see whether that gets rid of the problem altogether.

acer

Details

Hi, thanks for all of your comments, I will submit a report giving details of the systems that produce the error. In the mean time any suggestions on a work round would be greatly appreciated.

kernelopts(datalimit); is set to infinity. In the parent shell, typing ulimit -a tells me that

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
pending signals                 (-i) 1024
max locked memory       (kbytes, -l) 131072
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 65536
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

I'm not sure which limit would need to be raised? In case it's relevant, a typical example of when the computation produces the error message has memory usage of

 bytes used=33,107,336, alloc=11,008,032, time=7882.39

successful computations typically have memory usage values like 

bytes used=31,361,296,112, alloc=107,721,456, time=3735.86

Thanks, Steve

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
}