Timeline cache not updating when changing sim

[llllvm]

So I'm working with the new pyro tools in the 18.5 update, mainly in a sparse pyro dop network, however I'm encountering a weird issue that I sometimes had pop up in 18 where the timeline would cache my sim, but after editing a parameter within the dopnet it wouldn't clear the timeline to recache.

The particular edits I'm doing in this instance are changing the volume source field scaling, I've also tried doing edits with micro solvers like disturb but Houdini doesn't seem to be registering that things are changing.

I've checked the usual suspects, the auto caching brain is enabled, auto update enabled, and my dop node has enable caching checked on, and the dropdown menu next to the brain has it set to the correct dop node. Right now I'm having to control click the brain to force a recache when playing through the timeline, so not sure what could be causing this. I know the timeline is doing the initial cache correctly with a resulting blue bar in the timeline but it never seems to recognize when an edit is made to the parameters within the network.

This is running a fresh installation of 18.5 apprentice without any extra plugins or changes. Anybody else experience something like this?  Aside from the new pyro tools being used in the file attached I've had this same thing occur when running pop sims and pyro sims in Houdini 18 in previous projects.

explode_v001.hipnc

[Atom]

That's completely normal. With certain setups I am constantly clicking on the Reset Simulation button. It's annoying to have to jump up a level to do that. DOPs can't tell if a parameter that feeds the network has changed. So if you change, for instance, @pscale on the points that you supply to the network, that will not alter the generated cache, at least not until you issue a "rewind". In your case you have started the DOP simulation on frame #3. Try changing your start frame on the playbar to 3, instead of 1. Then a rewind might work for you. Or, change your start frame to #1 and time shift the final to frame #3 after you have locked in the simulation.

[llllvm]

Interesting, it's good to know this is not a unique problem just on my end. I'll try some of those frame range changes and hope for the best, thanks for the insight on what causes this to crop up.