Fire plume update

[martinjanssens]

This should ideally make us ready for the October training. Still need to:

• Add a surface entrainment, we get insanely large excesses now
• Add relative humidity to the plume, so we can see how far the plume is from saturating
• Add vertical velocity to the plotting options
• Ideally we want to launch and plot multiple plumes in the same sounding for sensitivity experiments.

[Peter9192]

Hi @martinjanssens really nice that you're able to work with this! Let me know if you need help/input or would like a review at some point.

[martinjanssens]

Right, thanks for the positive response, @Peter9192 :) It was quite okay working in the code. I changed quite a lot around the fire model to get the points above to work, so am happy if you look it over. I think I did most of it right, as I'm not breaking anything in my own tests.

I'm not totally sure whether I robustly solved plotting fire plumes: I had transposed the plume output to get it in similar form as CLASS output, so I could rescale the x-axis for large plume values. But when making the Plume line plotting function consistent with that output, I think I broke it, so I removed it and am now just using line plots.

For the future, I need to think about the surface-layer entrainment model, as it's now entirely arbitrary. But this should at least make the fire bit ready for the training in October.

[Peter9192]

Hi again, really good progress, and I understand from Chiel that the plumes look more realistic now. I'll focus on the code, not the physics.

I approved CI runs for this PR, you can see that they're still failing. One is a type error, I commented on that - easy fix. The other is from a test:

class-web/packages/class/src/validate.test.ts

Line 47 in c58a419

test("given emtpy object should return default config", () => {

Since you've updated some defaults in the config, we need to also modify the expected values in the test. This way of testing is not ideal, I agree, but at least it's better than nothing.

Concerning the transpose / back transpose, I think you may be losing some fire plume specific formatting (dashed red line). I might look into how you could fix the back transpose later. It might be good to think in general how we would like these plumes to be plotted.

One thing that does seem to break is the following: if I load a case e.g. Santa Coloma, and change the settings to activate the fire plume, it shows up fine. But if I then toggle to wind speed, I get an error. I think it might be because you're axes scaling implementation now tries to read from plume data, but that's not available for wind. You may need to make that dependent on whether showPlume is true or false

[martinjanssens]

That's really helpful. Thank you. I've fixed the two easy problems I think, and have tried to sort out the plotting of variables that don't exist for the plume when the plume plotting is toggled, by placing the generation of fire plume profile data behind a showPlume() condition. This removes the crash and gives the desired result (just a u-profile), but your helpful pnpm typecheck still complains. Here's where I don't know what I'm doing and might need more advice for a cleaner solution.

Regarding the plume-specific formatting: I've now just made all fire plumes appear in dashed lines in the same color as the CLASS environment they were launched in. So if you plot 3 permutations in the same plot with the fire plume toggled, we now get 3 environments and 3 dashed lines, where each plume and environment have the same color. This works logically for me in all permutations I can think of, including those that only modify the fire.

[Peter9192]

Nice work again! Sorry for the delay. I fixed the type issue in 3f34214. The 'normal' way to do this is by using a type guard (notice the v is PlumeVariable return type), but this doesn't work in this particular case since classVariable() is evaluated at runtime and therefore the typechecker can't confirm that it will return the same value as in the typeguard.. So I also explicitly cast the type (classVariable() as PlumeVariable). This overrules the type checking system so not the best solution, so use it with care.

Merged via #163, thanks for the contribution!

[Peter9192]

@martinjanssens I've invited you as maintainer for the original repo so next time you can commit/push directly to that one instead of working via your own fork