Glad to see this, explains why I haven't had any luck with that feature yet.

Another issue is, when time steps are set to a value greater than one and adding noise up-res I get this in *both* smoke and Smoke+fire in the latest alpha 2.83

@SlyNine (SlyNine) I'm not seeing that in 2.83Alpha-

Re the Feb 21 build of 2.83Alpha:
I also get a lot (most times I try in fact) of crash-on-load crashes in this build, trying to load previous build Mantaflow scenes.
I had to append all the objects into a new scene to actually load this scene, I could not load the scene without an instant crash. It loaded fine into the previous build. (I didn't test 'adaptive time steps' with this build yet)

Both 2.82 (if I import a scene baked in 2.83) and 2.83

Its a bit different than the other issue. In that it can take a lot more spread between frames to make it appear sometimes. I'll try to get a few more examples when I get a chance.

Hello, it looks like this issue has, very nearly, been fixed in the March 2nd build. The smoke looks smooth (almost completely) with time steps appearing to adapt between 1 & 8, and without the bake time being very slow.

I say 'very nearly' fixed, as you can still see a small gap/change in the smoke/fire, at the actual position of the mesh on each frame.
This scene was ok crash-wise for 'free data' & re-bake, but, as you can see at the end, this scene gives you a total crash when you attempt to playback in 'rendered' view mode. (see my comments in T73232 & T72214 re crashes and other issues with this (March 3rd) build.

Sorry it took me so long to get back to this. With March 4th version I'm still getting the same issues. Looking at your picture it doesn't look like you had the minimum set above one in the domain. I've attached more pictures.

@SlyNine (SlyNine) Agreed, if you set the minimum above 1 now it's broken with noise, but what I'm saying is that with the recent builds you don't see the huge stairsteps between frames anymore with minimum steps, like the image in my original report above, so something is definitely better. As in min=1 max=whatever, now looks better than min=2 or 3 used to. But I agree completely that if you raise the minimum it doesn't look too clever.

Here's min=1 with the March 3rd build-

Ohh it's a bug! That explains why setting CFL to a low value creates chaos: it wasn't increasing the steps automatically!

This is a really important bug to fix. Can't make a decent explosion without it.

I can confirm the original issue in blender-2.83-f06a6e92bc5e-linux64.

Im having the issue in 2.83 (sub 9), branch: master, commit date: 2020-03-17 20:42, hash: rBdc2df8307f41

Though it seems we can get better results using sub stepping on the emitter object than adjusting the timesteps

Sub steps 4 with time step min 1 - max 1, Very quick simulation

Sub steps 0 with time step min 1 - max 1

Sub steps 0 with time step min 4 - max 4 : Takes forever to simulate, You can see the turbulence force is much more apparent in this one though i'm not sure its behaving properly

Subframe handling has been improved with D7256. Can this be closed?

Sorry guys: I'm up to my neck with a promo & a music promo at the moment (50 clips to key and match-move for the music promo!) hopefully in a week or so I'll be back in Blender for the background plates so I'll be able to look at Mantaflow etc.

In T74062#902057, @Jacques Lucke (JacquesLucke) wrote:

Subframe handling has been improved with D7256. Can this be closed?

Sorry to say, but it seems even more broken for me. This is today's (April 2nd) release. Can you please confirm you have it working?

The buildbot version does not have Jacques's fix. You either need to build yourself or wait ~7 more hours from now for a new daily build. Please always include your build hash when commenting about a particular build as I'm only guessing you're using the buildbot right now.

In T74062#902381, @Jesse Y (deadpin) wrote:

The buildbot version does not have Jacques's fix. You either need to build yourself or wait ~7 more hours from now for a new daily build. Please always include your build hash when commenting about a particular build as I'm only guessing you're using the buildbot right now.

Got it, you're correct. Thanks.

blender-2.83-d0d20de183f1-windows64 - I just want to make sure that (d0d20de183f1) is the hash. Sorry for the noob question.

I'm still getting an issue when adding noise.

Without noise

With noise

I see, I can reproduce the issue when activating noise.

Ah, I know what the issue is. It's a bit difficult to explain: The emission for noise is only happening with the inflow from the last adaptive frame of the base simulation. That's why toward the end of the frame there is correct noise smoke/fire.

I'll commit a fix for this very soon.

Ahhh. Just as I expected. It's something to do with the flux capacitor.

In any case. Thank you! 🎉 🎉 🎉

c2cb87f8976b should fix the issue with the noise. ff2c67d7e8ed makes sure that there is no simulation before the first frame (was happening when using a high value in the "Adaptive Time-steps Minimum").

blender-2.83-(1239cab11ff9)-windows64

That seems to have fixed that issue.

I'm not sure if this is an issue or not. I assumed turning the CFL up would make them blender together more.

CFL at 4

CFL at 8

That's correct behavior: A lower CFL value will make the solver perform more simulation steps per frame. And thus the flow in between frames will be more smooth.

blender-2.83-(1239cab11ff9)-windows64

The only other odd behavior i've noticed is the speed of simulation. It seems some aspects of the simulation are fixed (so much per step)

Here I set the time scale to 0.01 and changed the minimum domain time-steps to 1 and 20 to exaggerate the effect as much as possible.

This is with the time steps set to 1

This is with the time steps set to 20

Nice! Thanks Sebastian. I'm yet to test it myself, but good to see another one marked as resolved.

Thank you Sebastian! I never did get around to testing that last bit. But the main issues seem resolved.