Factor exactly singular in d3, but not d2

[Adrian Fraser]

Hi all,

I've recently ported a triply-periodic IVP script to d3 so I can streamline a partly-quasilinear set of equations I want to simulate. While the d3 script works for some input parameters, I'm getting "Factor is exactly singular" errors for other choices of input parameters -- parameters that work just fine for the equivalent d2 script. 

I've attached equivalent d2 and d3 MWEs to demonstrate this. When the input parameter R is set to 1.1, the scripts produce consistent results. But when I set R = 2 (as in the attached), the d3 script throws this error while the d2 script runs just fine. When I set R = 2.01 or 1.99, I don't get an error but the simulation blows up after a few timesteps.

(I realize that, as far as d3 scripts go, this isn't really using any of the nice d3 features that are useful and make scripts cleaner -- I originally was, but then stripped it down as much as possible to be equivalent to the d2 script in my troubleshooting efforts.)

Any idea what's going on?

Adrian

[Ben Brown]

Adrian,

      From a very quick look, both the dt(u) and dt(v) equation appear like they're missing the dx(dx()) and dy(dy(()) parts of the laplacian on velocity.

Does anything change when you include those?

--Ben

--
You received this message because you are subscribed to the Google Groups "Dedalus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dedalus-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dedalus-users/7eda2289-650b-4b16-b2df-db90c951da50n%40googlegroups.com.

[Adrian Fraser]

Hi Ben,

I just checked and it doesn't address the error. Note that these dt(u) and dt(v) equations are only evaluated for the kx=ky=0 mode, so dx(dx()) and dy(dy()) are zero anyway.

Adrian

[Benjamin Hyatt]

Hi Adrian, 

I took a look at your scripts and I have a few notes to offer. TLDR: I wonder if the issue is the choice of initial timestep size (in the d3 script) being precisely 1/lambda_opt?

Main notes:
- The d3 script takes the initial timestep size to be max_timestep = 1/lambda_opt (this is specified on the line below # Main loop, and also as an argument passed to your CFL setup if you had used that instead). Conversely, in the d2 script, you currently specify an initial timestep size of 0.25*max_dt.
- When I change the initial timestep size in d2 to be max_dt, then I get the Factor is exactly singular error you mentioned.
- When I use basically any other choice of initial timestep size, I don’t get the error and the simulation proceeds to take many steps. For instance, if I perturb the max_timestep by 1e-14, the error goes away.

My reasoning is that the choice of dt = 1/lambda_opt is giving rise to a zero eigenvalue in at least one of the subproblems (I + dt*L) matrices. I would guess it is probably the R*w term because when I move that to the RHS the error goes away. Staying away from this dt will hopefully do the trick. 

Other notes:
- I also happened to try R = 1.9 and I again got the Factor is exactly singular error on the first step (in both d2 and d3). So R = 2 is not the only time this problem occurs. 

- When I tried R = 1.99 and 2.01 I don't recall the solution blowing up (the loop seemed to keep going for a while), although I wasn't checking the quality of the solution by plotting the grid data or anything. 
- In a few places in the d3 script you use a variable called dt (instead of the variable called timestep). I would recommend not using dt, since this can confuse the dedalus equation parser on terms like “dt(u)” if you are not careful.  

I hope this helps. Let me know if this checks out or if you are still experiencing issues. 

Ben

[Adrian Fraser]

Hi Ben,

Great catch, thank you so much! I thought I had taken care to make the d2 and d3 scripts identical, but I didn't think to scrutinize the timestep size, whoops. My bad everyone, false alarm. And thank you for the tips, I will be more careful with using "dt" in the future.

Adrian