Originally posted by: hugh_medal
Dr. Rubin,
Thank you again for your fast response!
I tried your recommendations. However, my problem persists. First, just so we are on the same page here is a more detailed explanation of the basic procedure of what I would like my code to do:
1. Generate a random sample of size 1500 from the set of all possible scenarios. Each scenario is a vector of parameters. Denote this random same as S.
2. Create a Cplex Model based on the sample S. That is, the model contains a set of variables and parameters for each scenario in S (like the deterministic equivalent of a stochastic program).
3. solve the model.
4. Generate another random sample of scenarios, denoted S'.
5. Modify the cplex model by replacing the set S with the set S' (using the setUB() and setLinearCoef() methods)
this is the step that is taking a long time 6. solve the modified cplex model
7. repeat steps 4-6 n times
Here are my responses to your recommendations:
1. "Were you creating a new model (and a new second model) for each scenario, discarding predecessors, or were you creating the initial model once, the extra model once and then modifying them for each additional scenario, or creating the new model once but the second model afresh with each scenario? I'm trying to relate the number/size of the second model to the scenario count to be sure I understand what's going on."
-
for this experiment, I created a cplex model (denote as m1) following steps 1-2 above. I then created a new cplex model following steps 1-2 while m1 is still in memory.
2. "That's good (certainly better than not leveling off), but depending on how many generations survive at steady-state, it could still indicate a problem with excessive persistence of some objects."
-
for this experiment, I performed steps 1-5 (without solving the model in step 3).
-
I examined the profiler results more closely. The number of surviving generations levels off at 14 and the heap size levels off at 13M. The leveling off takes places after the creation of the model (step 2)
3. "Most importantly, though, a typical Java program will not automatically try to grab the maximum memory it can. See
http://java.sun.com/performance/reference/whitepapers/tuning.html#section4.2.4 for some memory tuning tips. I think the default for the JVM's maximum heap size setting (-Xmx) is only 64MB. In the NetBeans IDE, you can go to Run > Set Project Configuration > Customize and use the VM options box to boost that. If running from a command prompt, you would add the option to the java command. In either case, try something like -Xmx2048 (to allocate 2GB to the heap) and see if (a) you can get away with it and (b) it helps."
-
I was able to set the max heap size to 1536MB (using the command -Xmx1536m). This change didn't seem to make a difference.
4. "All else failing, you can explicitly assign CPLEX objects a null value as soon as they have outlived their usefulness. That may make them eligible for garbage collection a bit sooner."
-
I assigned the CPLEX objects a null value as soon as I don't need them anymore. However, this also didn't seem to make a difference.
Do you have any other suggestions?
Thanks again,
Hugh
#CPLEXOptimizers#DecisionOptimization