Thanks for the reply, but I don't see the navigation panel in the database display. I already had v128 and just updated to v129 where I still don't see it.

Edit: I do see it in one of my reports. Does the GTO+ file have to be created in v128 or newer for it to be displayed?

Yes, the file does indeed need to have been calculated with v128 or higher.

Hey Scylla,

I tried to solve a database of 29 hands, but 5 said "Not enough memory"

Can you give me some insight into why?

Is there a quick workaround which isn't buying a better PC?

Can I use my external hard drive, for example?

Is there a way for me to solve for the 5 that failed and add to the same database?

Hi,
great job as always. Thanks Scylla.

I have a question about technical mechanics of the solver with regards to CPU temps. I bought a new pc with amd 3900x. It seems to solve fast, but it also quickly reaches 95C. I read that those temps are long term...suboptimal.

Before I buy a new cooler, I had an idea that gto+ might force CPU to throttle regardless of the cooling, just because the algo can utilise all available compute power to the max, even if I had 100+ cores. Like if it fully utilises huge aws servers, what is another cooler going to change? I did not OC and was told that stock cooler is good enough anyway.

Does that mean that I should skip buying a new cooler and try to undervolt cpu/make sure that the highest temp the cpu is allowed to reach is lower? I realize that would slow down calcs a little bit.

thanks

oh and this is not a big deal, but sometimes export into flopzilla pro doesnt work. It seems to be random, but the button is sometimes greyed out. I assume I'm making a ridiculous boneheaded mistake somewhere, does anything come to you by any chance? thanks again

Different boards require different amounts of memory. Most notably, unpaired rainbow board require the most RAM, and monotone boards require the least. Other than that though, if the solver starts regularly, but stops at a later point, then it may be that more RAM is required. If you turn ON "Run indefinitely if solver has trouble converging" (click on the GB button in the bottom left part of the interface) then it may still solve.

If at full capacity the CPU can reach temperatures that can damage it, then your system is not properly cooled. It should basically not be possible to overheat a store-bought computer. For example, if your car started smoking when driving the regular speed limit, then someting would be improperly configured as well. Your CPU should be able to handle these operations. I would definitely recommend looking into your cooling.

The button will be grayed out in Flopzilla if no range is entered.
This is because in this case there's nothing to export.

When trying to simplify solutions, what kind of maximum EV loss should we target ?
.5%, 1%, 2%, 5% ?

Are you referring to dEV?
The lower the dEV, the better.
Generally I would recommend 0.5%.

No, I'm comparing the EVs of the GTO UTG flop strategy (in UTG RFI vs BU call), to the EV of the UTG simplified strategy.
Only variable changed is the strategy used, tree data don't change (UTG can either bet 75% pot or check; dEV is set at 0.5% in both cases).

I expect to always have a loss of EV when deviating from GTO solution, but how big a difference % is acceptable ?

> UTG simplified strategy
simplified using nodelocking

You can't look at a percentage, you need to look at the actual EV loss, and take into account how often the situation you are studying happens, and the impact it has on your winrate. Losing 5BB in a spot that occurs once every 1000 hands isn't as big of a problem as losing 5BB in a spot that occurs every 100 hands.

As an extremely simplified example, if you are looking at a situation that occurs once every 100 hands on average, and your simplified strategy makes you lose 1BB compared to the GTO strategy, your winrate in BB/100 will simply go down by 1BB.

This is why people study more the situations like BUvBB that are more common, because even a small loss can make a big difference if repeated often.

Besides the cooler for the CPU you also have to take into account the quality of the VRM in the motherboard. Not all b450 for example have good VRM's for the 12 core processors or for the 16 3950x. Search in youtube for your model motherboard and vrm and you'll find the info if it's good enough.

Have been running identical sims in gto+ and pio and getting really different results. There is still some variation in the threshold conditions pio vs gto+ imposes, but I don't understand why there would be such large difference in frequencies.

OK, ty.
This is a valid and useful remark in general, but not really helping answer my question.
Suppose I'm talking about a BU open vs BB call formation.

Solving this tree, I get a GTO solution yielding a particular EV.
However it's difficult/ impossible to implement that exact solution in game.

Although it's very interesting to try and understand why the solver got to this solution, it's also very interesting to try and simplify as much as possible the solution.
If we can simplify it to the point where it's easier to understand and implement, while losing a negligible EV amount, that becomes very useful and valuable : losing a bit of EV to the GTO solution, but still being closer to the GTO than playing without reference to the optimal solution.
Also, let's put aside exploitative considerations.

However, a 10% EV loss for the simplified solution compared to the GTO one would not be acceptable.

My question is : how small of an EV loss is reasonably achievable and acceptable when simplifying a GTO solution ?

Scylla, I find it quite easy to nodelock using the right click to isolate hand categories. But I would like to be able to right click individual combos in the matrix, that would make it even easier to nodelock and assign actions to particular hands in the table.

Hi. Can I save a hand ranking in GTO+, as I can in CREV?

I found the file, in C:\Program Files\GTO\config, but can't get permission to edit/save it.

Solved now.

Thanks
Rod

For the range matrix, could we have the display options available in the analysis matrix ?
I'd like to be able to visualize ranges with the "display method 2" available in the analysis matrix.

Ok, I will consider it for future releases.

Ok, I will see what I can do here.

When trying to interpret solutions, I would not simplify, but instead look at hand types (top pair, flushdraw, etc) and try to figure out why certain strategies are used. By trying to focus on understanding as opposed to memorizing it should be much more feasible to arrive at strategies that can be applied over the board in different types of situations. The problem with simplifying is that you're actually losing detail that may be helpful in understanding solutions. As for which % is acceptable, I really can not give an answer here, given that this is very subjective.

First of all, in order to make a comparison, the trees need to be exactly identical. The GTO+ and pio tree builders are slightly different, and will not create the exact same tree. So if you used the advanced tree builder for both programs, then the trees will be different. Currently, only GTO+'s "Basic" tree builder builds the exact same tree as the V1 tree builder for pio. In this case the results will be almost identical.

Other than that, if you're using multiple bet sizes, then please note that each bet size performs nearly exactly the same as any other bet size*. As a result, within any given dEV, many different configurations for the frequencies are possible that all fall within the same Nash distance.




*=You can check this for yourself by building the same tree, but for different bet sizes and then checking the overall EV (this is OOP's EV below the table in his very first decision). As you will find, these EVs will be almost the same for each bet size.

Thanks for your advice !

Hi Scylla,

You mentioned before that the solving time is depending or the cpu speed and the number of the cores. Does this mean that if you have for example 32 cores instead of 16 with the same frequency that you should solve the same tree 2 times faster?
And does it matter if you use physical cores or hyprethreading?

The new update gives me different results for the same tree as the one before it, including some INCREDIBLY funky stuff. It's also dramatically different from pio or simplepostflop.

Ok, can you send a savefile to support?