Decision Optimization

Decision Optimization

Delivers prescriptive analytics capabilities and decision intelligence to improve decision-making.


#Analytics
#DecisionOptimization
#DecisionOptimization
 View Only
  • 1.  ILOG Concert Java: modifying the model

    Posted 04/10/10 02:34 PM

    Originally posted by: hugh_medal


    Hello,
    I trying to the sample average approximation method in CPLEX (using ILOG Concert-Java) to solve a stochastic program. In this problem, only the rhs and variable coefficients of some of the constraints are random. To estimate the lower bound of the problem, I take N samples from the set of all possible scenarios. For each sample, I solve the extensive form of the stochastic program using CPLEX.

    In my implementation, create the CPLEX model once and then modify the parameters of the model for each sample. I am using the setUB() method of IloRange and the setLinearCoef() method of IloCplex to modify the model parameters.

    My problem is that modifying the model takes a long time. I am trying to modify 7000 constraints of the model. This task takes about 20 seconds. The entire model only takes about 1-2 seconds to create.

    Is there something I am doing wrong?

    Thank you for your help,
    Hugh Medal
    Ph.D. candidate
    University of Arkansas
    #CPLEXOptimizers
    #DecisionOptimization


  • 2.  Re: ILOG Concert Java: modifying the model

    Posted 04/10/10 05:37 PM

    Originally posted by: SystemAdmin


    It's possible the JVM is getting busy doing garbage collection. There are a couple of things you could try to test that. One is to boost the maximum heap space (see, for instance, http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp). If you get at least a few scenario changes before things slow down, you may indeed be running low on memory. Another possible experiment is to generate and solve the model, then generate a second model (while the first is still in memory). If the second model takes notably more than a couple of seconds to generate, it again may be a space limitation. (Using a memory profiler would also answer the question, if you have one.)

    If you are in fact running low on space (forcing the garbage collector to work harder), one answer is to boost memory, but you might also look around to see if you're hanging onto temporary objects beyond their useful life. If a temporary object is going to sit in memory a while before dying naturally (say, by going out of scope), you might try to expedite their demise (set them equal to null, for instance).

    /Paul

    Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
    #CPLEXOptimizers
    #DecisionOptimization


  • 3.  Re: ILOG Concert Java: modifying the model

    Posted 04/12/10 12:26 PM

    Originally posted by: hugh_medal


    Dr. Rubin,
    Thank you for your very prompt reply. I performed some the tests that you suggested. However, I still am experiencing problems with performance.

    Here are the results of some the tests that you suggested:

    1. Create a model and solve it, then create a second model with the first model still in memory: I tried this and for 1500 scenarios, the second model took the same time as the first to create. However, with more than 5000 scenarios, a OutOfMemoryError is thrown.

    2. Run memory profiler: I used the NetBeans profiler per these instructions: http://netbeans.org/kb/articles/nb-profiler-uncoveringleaks_pt1.html. The results showed that the number of surviving generations is leveling off after awhile.

    3. Increase memory: I am currently running my Java program using NetBeans 6.7 on a Windows server with 4GB of RAM. I checked and I am the only user running programs on the server. Is this enough memory?

    4. Check to see if any objects are hanging around too long: I didn't find any objects that are obviously hanging around too long. I made a few minor changes to my program but these changes didn't seem to help.

    Do you have any other ideas?

    Thanks again,
    Hugh
    #CPLEXOptimizers
    #DecisionOptimization


  • 4.  Re: ILOG Concert Java: modifying the model

    Posted 04/12/10 02:49 PM

    Originally posted by: SystemAdmin


    > hugh_medal wrote:

    >
    > 1. Create a model and solve it, then create a second model with the first model still in memory: I tried this and for 1500 scenarios, the second model took the same time as the first to create. However, with more than 5000 scenarios, a OutOfMemoryError is thrown.

    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.
    >
    > 2. Run memory profiler: I used the NetBeans profiler per these instructions: http://netbeans.org/kb/articles/nb-profiler-uncoveringleaks_pt1.html. The results showed that the number of surviving generations is leveling off after awhile.

    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.
    >
    > 3. Increase memory: I am currently running my Java program using NetBeans 6.7 on a Windows server with 4GB of RAM. I checked and I am the only user running programs on the server. Is this enough memory?

    4GB of physical RAM does not mean 4GB of RAM available to Java. The system eats some. Depending on whether the Windows server is running a 32- or 64-bit version of Windows, and how it is configured, there will be different ceilings for how much physical memory can be allocated to a single process. See http://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx for details (the section on "Memory and Address Space Limits").

    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.
    >
    > 4. Check to see if any objects are hanging around too long: I didn't find any objects that are obviously hanging around too long. I made a few minor changes to my program but these changes didn't seem to help.
    >
    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. The first thing I would try, though, is the -Xmx switch (item 3).

    /Paul
    #CPLEXOptimizers
    #DecisionOptimization


  • 5.  Re: ILOG Concert Java: modifying the model

    Posted 04/12/10 05:09 PM

    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


  • 6.  Re: ILOG Concert Java: modifying the model

    Posted 04/12/10 05:37 PM

    Originally posted by: mrr_1010


    Hi Paul and Hugh,

    I just wanted to briefly document that I have also encountered this problem. I find the modification of the models in Java surprisingly slow. In my case, I just wanted to iteratively update some constraints and objective function. It was not in a particularly large model and java heap did not seem to be an issue. I just thought it was driven by how Cplex and Java communicate with each other and that there might not be much I could do about it.

    I will check some of the proposed solutions, but in the meanwhile I just wanted to suggest that this might not be an isolated case.

    Many thanks!
    Mar
    #CPLEXOptimizers
    #DecisionOptimization


  • 7.  Re: ILOG Concert Java: modifying the model

    Posted 04/13/10 10:25 AM

    Originally posted by: SystemAdmin


    Well, it does not sound as if garbage collection is the culprit.

    There's a distinction between the model and the solver instance. When you solve the model, CPLEX "extracts" the model and creates a solver instance (explicitly in C++, implicitly in Java). Thereafter, any time you change an element of the model, CPLEX has to notify the solver instance of the change, which adds overhead. Daniel's second bullet gets at this. I'm not sure about the details, but I suspect that, for example, iterating through the coefficients of a constraint changing them one by one would be considerably slower than replacing the entire left-hand side by a newly constructed linear expression, since the former would involve multiple change notifications and the latter would involve a single notification. I don't think you would see this difference (or see it as significantly) prior to first solving the model, since the first call to solve (in Java) would trigger extraction of the model.

    Daniel's suggestion about deleting/replacing whole constraints fits with this. The fewer notifications involved, the better.

    /Paul
    #CPLEXOptimizers
    #DecisionOptimization


  • 8.  Re: ILOG Concert Java: modifying the model

    Posted 04/13/10 07:33 PM

    Originally posted by: hugh_medal


    Thank you Daniel and Dr. Rubin!

    Indeed, after I started removing constraints and re-adding them (rather than trying to modify them), the run time improved. It now takes around 0.75 seconds to replace all of the constraints in the model.

    Regards,
    Hugh
    #CPLEXOptimizers
    #DecisionOptimization


  • 9.  Re: ILOG Concert Java: modifying the model

    Posted 04/13/10 01:06 AM

    Originally posted by: SystemAdmin


    If you say that creating the model is fast but modifying it is slow, have you tried any of the following:
    • Setup the variables and constraints in an instance of IloLPMatrix and perform all modifications on that object. In each step create a new Model based on the IloLPMatrix instance.
    • Instead of modifying the constraints remove them and create new ones from scratch.
    • Combine the two things above: setup only the 7000 constraints that will be modified as IloLPMatrix and remove/re-add only these constraints.

    #CPLEXOptimizers
    #DecisionOptimization