Submind YouTube summaries
Thumbnail for Lecture 6: CAMulator & CREDIT | 2025 EdEC Machine Learning Bootcamp

Lecture 6: CAMulator & CREDIT | 2025 EdEC Machine Learning Bootcamp

Watch on YouTube

Video summary

The lecture introduces CAMulator, an autoregressive machine learning emulator developed in-house at ENCAR to imitate the Community Atmosphere Model (CAM). Unlike generative models that learn from compressed data distributions, CAMulator operates by taking inputs at a specific time step and predicting outputs six hours later, which then become the inputs for the next prediction. This sequential process allows the model to generate realistic atmospheric states, such as specific humidity patterns associated with the diurnal cycle. The training data consists of a 35-year simulation using historical sea surface temperatures from 1979 to 2014, covering prognostic variables like wind and moisture across multiple pressure levels, along with diagnostic outputs like precipitation and clouds. To ensure physical realism, the model incorporates conservation corrections for dry mass, moisture budget, and total atmospheric energy, resulting in a compact architecture of roughly 750 million parameters that is significantly smaller than large language models like GPT. A key advantage of CAMulator is its computational efficiency and stability over long time scales. While traditional general circulation models might simulate only a few years per day on high-performance computing clusters, CAMulator can generate approximately 480 simulated years in a single day on a single GPU. This speedup allows researchers to run massive ensembles for climate studies that would otherwise be computationally prohibitive. The speaker demonstrates that the emulator maintains stability over 200-year simulations and accurately captures long-term modes of variability, such as El Niño-Southern Oscillation (ENSO) signals in precipitation patterns, even though it is trained on short intervals. Furthermore, the model can follow observed warming trends when forced with historical sea surface temperatures, showing that it successfully mimics both internal climate variability and external forcing effects without drifting into non-physical states. Beyond CAMulator, the presentation highlights the CREDIT platform, a comprehensive toolkit led by DJ designed to facilitate the creation and deployment of custom emulators. This platform integrates pre-processing tools for various datasets like ERA5 and CESM, offers a library of neural network architectures including Wav2Vec and SimulR, and provides scalable training infrastructure on ENCAR's HPC systems. The speaker illustrates how users can easily customize an emulator by simply editing configuration files to include new variables, such as soil moisture or land surface temperature, without needing deep expertise in machine learning code. Additionally, the lecture discusses advanced techniques for generating ensembles, including perturbing initial conditions and exploring latent space methods to quantify uncertainty. These capabilities enable applications ranging from rapid ocean spin-up, which reduces compute time from months to hours, to subseasonal forecasting challenges where coupled atmosphere-ocean models provide more accurate results than prescribed forcing approaches. Despite its successes, the development of machine learning emulators faces several ongoing challenges, particularly regarding out-of-sample fidelity and chaotic error growth. The speaker notes that while the model performs well within the range of its training data, predicting scenarios with significantly different conditions, such as a four-degree Kelvin increase in sea surface temperature, can lead to divergence from physical reality if not carefully managed. There is also an inherent smoothing effect in autoregressive models that can dampen fine-scale weather signals over time, though techniques like multi-step training and stochastic forcing help mitigate this issue. The community is actively working on systematic evaluation methods to ensure these emulators represent physical processes accurately across different time scales, from fast atmospheric dynamics to slow ocean circulation. As new versions of the underlying physics models like CAM7 emerge, there are plans to retrain emulators to maintain consistency, ensuring that these AI tools remain reliable for both weather prediction and long-term climate projection.
Read the full video transcript
Hi everyone, it's me again. Um, [laughter] um, after Daniel's talk, I thought it might be kind of cool to talk about an emulator that we have in house. He talked to Earth, he talked about Earth2 Studio, which is a platform for us to actually use emulators um, easily. But I wanted to talk about that we actually have emulators inhouse and we actually have a platform for you to generate your own emulators um through the miles group which is led by DJ. So I'm going to briefly talk about what an emulator is, talk through emulator um which is one of the emulators we have and then also talk about the um credit platform which is how we can actually generate these at Encar. Um and then I just want to reiterate I'm the messenger here. The main lead of CMulator was Will Chapman who's now a professor at CU Boulder. All right. So, just to define emulators. Emulation. Oh, you're just making up. Okay. Emulation refers to the ability, this is from Wikipedia, so trust that as you want. Emulation refers to the ability of a computer program and an electronic device to emulate or imitate another program or device. So when we talk about machine learning emulators in earth system science, what we're referring to is the ability of a machine learning model to emulate or imitate one of our traditional models. It's as simple as that. So there's two main types of machine learning emulators. There's the auto reggressive um model which is a lot more similar to like our climate or our weather models and then there's the generative model which is kind of a mind game um if you're not as familiar with this type of model. Um but camulator is an example of an auto reggressive model. So basically all that means is that you have input that you put into your model. It outputs something. That output is then passed in as the input to make another output which is passed in as the input to make another output. And that's how we roll out our forecasts. On the other hand, there's a generative model which actually learns the distribution from your training data or generates states from a learned compressed representation of climate data sets. And I think the best way to understand this is through an example. So climate in a bottle is an example of this. It was generated by Nvidia. Basically all you give this generative model is these conditions that it must follow. And one of them is the day of year, then there's time of year, and then there's monthly average sea surface temperatures. And from these three variables, it'll generate a climate state for you. Um, it outputs 11 surface uh variables and four pressure level variables. Um, and I linked both these papers at the bottom here for climate model and came later if you're interested in learning more. Um, do we have any questions about >> Yeah, >> I guess to kind of the more in context are the ideas that like autoressive is more prediction focused and generative is more like analysis kind of. >> So generative you can actually in a predictive sense. um where you can't really necessarily like follow the trace of a specific like weather feature, but if you put in like your monthly SSTs in sequential order while the atmospheric state isn't going to be like identical, you could in in that regard and I think they show an example of that in the app. Yeah, there there also some ways it so if if you actually uh the way like in a bottle some of the models are set up they just like kind of sample from a completely random distribution but if you kind of like the other stochastic methods if you have like structured random noise that has is correlated in time and space then and you know the random seed for that noise generating process you could force a trajectory that has a stoastic forcing to it that's so like each trajectory is deterministic but but with a different stochastic route. So, so there are ways to mix the two. You have to you have to be more you have to be more intentional about it. Okay. So, just some general background history random things that popped into my mind when I think about machine learning emulators in the earth system sciences. We've mainly been focused on weather time scales. So far, most emulators are trained on Aero 5, whether that's good or bad. Um, we've been dominated by atmospheric emulators, but ocean emulators have started to appear and have started to be coupled to atmospheric emulators. Um, typically when we hear of climate emulators, they're referring to an AIP style simulation. Um, though this is quickly changing as I just mentioned with the coupled emulators. Um, and then there's this new focus on substance to seasonal uh time scales that people are interested in. Okay, here's a quick promotional video of the AI model that we're going to talk about. This is Camulator. Um, this is specific humidity at the lowest model level. And as you can see, it looks quite physically realistic. And I'll I'll show that it actually is. And I'm going to step through how this was actually trained to get what we're seeing in this great video. I think what's kind of cool is you can see the pulsing of the specific humidity. I'm assuming is associated with the dal cycle. Actually don't know the the temporal frequency of this video. Do you? >> I think it's six hours. It's >> six hours. Yeah. Just let it play for a little bit longer. Okay, so let's talk about camulator's training data. So when I say camulator, [clears throat] this is an emulator of CAM. CAM is our community atmosphere model here at ENCAR. And so what Will has done is he generated a 35-year CAM simulation and saved out six-hourly time steps for from this model. This is using um an AIP style run using SSTs from 1979 to 2014. So we basically have this long giant time series of six-hourly time steps for a variety of variables. And what CAM is tked to do is take an input at time t and predict 6 hours later. And that is all it's trained to do is take in t predict six hours later. There's no auto reggressiveness in this training process. So in terms of the training data, I want to talk about some variable um definitions. So we have prognostic variables. These are input and output by the model. We have diagnostic variables. These are only output by the model. We have um and then we have uh forcing variables and this is only input into the model. So I took the liberty to mess with this table and put it into an input table and an output table. So in the green highlight we have our input features and in our out table we have our output. So on the left hand side we have our prognostic variables and our forcing variables. These are our inputs. Prognostic has UVT and Q. These are all on 32 um hybrid sigmo pressure levels. Um and these are all 2D plus vertical. Um then we have two surface variables. So we have surface pressure and near surface air temperature. And then we have our dynamic forcing variables. So we have incoming solar radiation and sea surface temperature. And these vary dynamically with the simulation. So we have an update every six hours to force the model. And then there's the static forcing variables which is um surface uh geopotential which is to tell you about the top topography um of the earth and then the land sea mass to let you the model know whether it's an ocean or a band. >> So what's the resolution of the angle of the output for that? >> Uh one degree >> yeah one degree >> one degree >> 192 by 288. So it's still somewhat degree technically but >> all right. So then um do we have another question there? Okay. So then um we output UVT and Q at all 32 pressure levels. Then we have our surface variables that we also input. Those are output six hours later. Then we have all of 15 diagnostic variables that are also output. So this includes precipitation, clouds, wind stress, uh 10 meter wind speed, and a bunch of fluxes that are all output by the model. So all of these variables are included in our loss function when we actually update the machine learning models weights. So we're actually minimizing all of these these variables, the loss of all these variables. >> Is that cam 6? >> Yes, I think I have. Yeah, cam 6 and CSM v2.15. Okay. So, I made a simplified diagram of this um architecture of this model. Um, and I have the the real one that's in the paper. So, I'm just going to step through this one and then we'll jump to the a little more daunting one from the paper. So, basically all we have is some atmospheric variables that we put into our machine learning model and these four scenes. This is passed through um a bunch of layers that's in this uni unit struct like structure. Then um they've also included these um conservation. So they have a non- negative correction, dry mass correction, moisture budget correction and a total atmospheric energy correction. And then we have our outputs. Some of these outputs are then when we actually roll out the model are then put back as inputs into this model. And then the the coloring just represents the types of layers. But this is not necessary to understand for this talk. So um just to mention some of the terms that we've talked about here. Um the data is normalized using a zcore normalization. So it's subtracting the mean dividing by the standard deviation. All of the variables are standardized this way. The loss function is a latitude weighted mean squared error. It's trained for 190 epochs. The optimizer is atom W. The learning rate is 1 e to the minus5. It also has a scheduleuler that um updates the the learning rate as you train and the batch size is 32. So these should all be slightly familiar names to you guys in terms of actually training a machine learning model. So this is the schematic from the actual paper. So the the top half here is um similar to what I already showed. So we have our inputs. It's passed through the model. We have our physics um conservation. And then we have our output. And then the uh B, C, and D of this panel describe the actual architecture um of these individual layers. What's interesting about and really cool about this model is it's on the order of a thousand lines of code. Um it has 750 millia parameters. It's about 0.5% of GPT chat GPT and it's only 2.8 8 GB in size. Okay, so now that we've trained this machine learning model, let's talk about how we actually roll it out into the future. So typical to our general general circulation models, we have our input in in these GCMS. We then have our grid scale dynamics. This is just for sub um grid physics. And then we have our conservation corrections and we get an output. That output is passed in as input and then we roll it forward again. Exactly the same process here. Instead of grid scale dynamics and subgrid physics, we have an encoder and decoder. We do those conservation corrections and then we take some of those outputs and use it as input into our model. So basically what if going back to these tables, we have our input variables and we have our output variables. A subset of these output variables are then passed as input into the model and we can roll this out in six hourly time steps. So let's say we wanted to roll out camulator for 200 years. I mean this is part of our climate model. So we want to make sure that this is actually stable. So we are rolling it out in terms of six hourly time steps to get to 200 years. And this is showing the column integrated heat content of cumulator. Um the actual camulator run is in all those squiggles. This is forced by the 2000 climatology um sea surface temperature. And what we see is if we calculate the long-term trend, which is in this dash black line here, it's relatively flat, which is what we would expect um given given this situation. Okay. What if we want it to look like observed the the observed past? This is um CAM and CAM from 1979 to 2013 SST. So CAM's in purple now. Camulator is in teal. Um and this is a 12 member ensemble of camulator compared to CAM 6. And what we can see is when we force it with observed SSTs, it generally follows um CAM which is what we would hope. Uh interestingly as well, we also get this slight um increase in the column average um key content which is suggesting that it's actually able to get this warming trend as well as internal variability. What I find really interesting about camulator is even though we're also taking these six-hourly time steps, it can get these large long-term modes of variability. So, here's an example of the precipitation response to Enso in CAM in DJF and in CAML um in DJF. And the pattern correlation here is 0.9, which is really good. So, I find that pretty neat that we're able to even though we're taking those six-hourly time steps, we're actually able to get this this signal. Um, I also just wanted to include some climatological mean biases. Um, he's also included here um some observed or reanalysis type features. So, we have GPCP and AR 5 for precipitation and temperature respectively. Um, but it's important to note that we're emulating CAM and not the real world. So we're trying to match CAM and not the gray dashed lines here. Um and this is just um yeah those biases. >> I have a quick question. >> Yeah. >> What provides the randomness of the 12 member ensemble? >> Uh >> is it just perturbed initial conditions? >> I think it's perturbed initial conditions for for >> I think it's Yeah. >> Yeah. Just purve initial conditions. We're not doing the other stoastic stuff >> for ST. >> Yeah. >> Yeah. SST it's >> after about 14 days we it basically gets into that like but when we see the the error growth and then by 14 days you're you're essentially in different trajectories. >> Gotcha. [clears throat] >> Okay. Another thing um that I think is interesting is what is what happens when we have out of sample distributions which is typically what we use climate models for. So um what Will's done is he's taken the 2000 SST climatology and he's added in 2 Kelvin uniformly and 4K or 4 Kelvin um to camulator uniformly. So the uh the dash lines are for cam and the non-dash lines are camulator. The blue is an example of the 2000 climatology. The orang-ish brown is for when we add the two um Kelvin and the green is when we have um the 4 Kelvin. And what you can see is from the the top we have our lowest temperature model level all the way to a a 200 to 850 x pascal integrated heat column heat content. And what we see is that as we move away from the surface since we're not we're forcing this basically forcing this surface through the SSTs. As we move away from the surface you can see that the green really diverges. um between cam and camulator. All right, that's camulator. Do we have any more questions? >> Yeah. Yeah, Kirsten, thanks. Maybe you or DJ could talk a little bit about like the motivation behind why Camulator was developed and some of the use some of the use cases that you see going forward. >> Yeah, I can I can talk a little bit. I think part of the motivation of it was we wanted started with want to train a model on something other than error five. So so pretty everything was train has been trained on error 5. Uh the problem with error 5 is that it has well is a good a good representation of the atmosphere like the atmosphere as it is based off of the IFS and the data simulation practices at ECWF. It does have limitations. There's artifacts from like bringing in satellite observations that show up in the fields. There's uh unrealistic jumps and uh when whenever a new uh data simulation update update stuff happens and sometimes the models kind of struggle with with with dealing with those. Um some of those we wanted to see be able to yeah extend this to cl kind of climate time scales and see how can we roll out stably for a really long period of time. I also have more control like when you train off of a a climate model run everything should be self-consistent so you don't have some of the weird jumps that you get with with a weather fields. We also will decide to use average fields which um in some way will like damp out some like finer scale weather like signals but but for client purposes if you're wanting to do longer term averages it makes sense to do that. Uh so so there there are some performance benefits there. Uh we want >> means using six hourly average bills instead of instantaneous. >> Yeah. Yeah. Um some of those Yeah. We we had developed physics constraints set the weather scales. They want to see if those would help us at the climate scales as well and just have another application of credit but that using an incar based data set. So we would have kind of our entirely our own product from end to end and and not be relying on another center for for data. uh in terms in terms of what we can use this for. I think that the there's a lot of different applications. I mean in the longer run you want to couple a camulator with a mulator and a climulator and a CI later and so on and have have a full CS simulator. Um uh and and we can also use this as a so so one application if you're running like uh you only care about the upper atmosphere or you only care about the ocean or you only care about the land and you but you want it like a a coupled atmosphere that runs really fast and isn't your bottleneck on getting the results you want. the emulator has very attractive compared with prescribed forcing which isn't interacting with your your system because you there are a lot of studies they're showing if you have a coupled atmosphere versus a prescribed atmosphere you get very different results. So so there's so being able to like one goal we want to have it is is actually coupling this with not just other AI models but with physics based models and and uh seeing how how how effective that can be. Uh also ocean spin up I think is another use case that's come up. Uh if you can spin up an ocean with like a mulator uh like that currently I think takes like two months of compute time uh for the part of the run you basically throw away. Uh so if you can do that in two hours uh or or a day or whatever then that's that kind of changes a lot of what you could what kind of science you could do. Um I think there's other applications we can talk about more in the Q&A. So I I'll stop there. >> Okay. >> There's a question online. Um how long compute time did it take to train? >> 3 days on 32 GPUs. So uh and we could probably speed it even more. >> Is this enough? Uh I I mean compared with so like like a lot of if you're at I feel like quarter degree it usually takes a couple two to three weeks to to train. Uh there's probably we think there's some ways to speed it up with how you do the data pipelining. Um we could probably get even get this down to one day if we if we were really ambitious. So some of this is like how much like multi-step training do you want to do? How like how well is it converging? Um how how many variables are you predicting? So, so there's there's some light math you to to to play around, but but order days I would say for for training a camulator uh at at one degree for me clip will probably take weeks. Uh if we want to do a mea clip later um which we we want to do um >> because of the higher resolution spatial resolution. >> Are we sticking with the you later naming architecture or are we taking suggestions? I think that would be a problem for discussion but CGD and emulator team that's thematic thing you want to keep doing for now always rebrand at some point [clears throat] it does seem to be popular >> sorry go ahead you have a question yeah >> oh wait for me sorry yeah no well maybe to come answer I'll just you know you trained on cam six but cam 7 is definitely going to be here any day now and So, uh, like was there plans of like, oh, just retraining it again on Cam 7? Yeah, I guess like going to the future plans like anytime a new version of these models comes out, do we want a new emulator for that or is it kind of only when there seems to be a desire for it? Yeah. Yeah. >> I mean, that's something I've discussed with Dave Lawrence is have you I don't say if you have a firm commitment, but certainly you you once you have a new version of CAM Yeah. you do you do some test you do you do some long runs and train and then train a train a new off that it's it's it's quite feasible to do to have and then then do some scientific validation on it and and release that or some mix of them with with w with a new CSM release I mean >> yeah cool thanks >> yeah Judith >> can you talk a little bit about um that problem of um AR models or auto reggressive models with the smoothing and how that was dealt with there. >> Um I don't think the smoothing was necessarily dealt with. It does smooth um but I I think whale has a new upsampling or um decoder part of the model that um makes the smoothing a little bit less. But yeah, typically with auto reggressive models, you ultimately end up smoothing the output of your field as you um roll it forward. >> So Delan has this this thing that if you don't train one time step, but two time steps, it's one way to avoid the smoothing. Say that >> one still it seems to help a little bit. It doesn't get completely get rid of the problem though. And a lot of Dale stuff is also at much coarser resolution. And so it's not clear that it's helping at the final resolution. Also seeing his like from the act people running his stuff for predictive purposes seem like the model actually seems to struggle quite a bit. So I I think it's like two time steps isn't like there can be some advantages but it also comes with the computational overhead of having to predict a whole extra state. Uh some of the stoastic so like doing cops training seems to also help with smoothness. uh having more explicit vertical like um interactions also I think are would would would help some of the smoothing issues because I think under the underlying issue with the smoothness is we're not capturing all the processes we need to capture there's basically the neural network is trying to is just I can't I can't resolve that so I'm not going to I'm not going to predict it so unless you do it if you do it stoastically then then that issue kind of goes away but because you're sampling from a distribution rather than predicting the mean but if you have more information to condition your mean so that it's got a smaller space to smooth over. It should get less smooth. >> Thanks. >> Yeah. >> Kind of related to that, um, do one of you guys want to sh talk about a little bit like the differences between single step training and multi-step training and what that applies? >> Yeah. Um, so can I didn't mention this here just to keep things simple, but camulator actually has two steps of training. The first is it takes a six-h hourly time step and then the second version of training that it does is it does take um two time steps. So it does 12-hourly and then calculates the loss. I think it's the average loss based on those two time steps. Um and also includes the conservation then they found when they included the conservation um in the earlier training that the model didn't do a good job at training. So that's why it's it's later on. >> There's another question from Alison in the chat for for the cany. Can you say more about how many times did you need to retrain to figure out batch size number of box hyperparameters? >> I do not know that answer. Do you know that answer? >> Uh more than we care to admit. [laughter] We there certainly a lot of especially during the initial um like credit development process we we uh there were a lot of iterations on architect on figuring out a lot of the details a lot of like oh this didn't work right let's try something else and uh thankfully many lap like in addition to our sizzle allocation CGD and then cute are also happy to donate some of the GPU allocation under ratio for to to to this effort so um [clears throat] >> but now that we have it I've actually used this architecture to train something else which I'll briefly talk about later. Um, and I didn't have to adjust anything. So and that we have >> say I think that brings up an interesting point that like I think hyperparameter optimization for like pretty big models like these is kind of like you know a challenge right now in the field and it doesn't necessarily follow like the same paradigm of this kind of traditional hyperparameter screening in other models where you might be able to do brute force or even kind of have a you know smart kind of sampling procedure that the resources are just so much that there's a lot of unexplored space. Yeah, these bigger models. >> Yeah. Yeah. We're going to have to rely more on either proxies from like training a smaller version of the model and seeing if that those those parameters generalize to a bigger version. Um kind of relying on how fast is the loss going down. So only train it for like an epic or two and like then then just being really aggressive about kicking out candidates that don't seem to be doing well. Uh being more responsive to you know comp computational balance. Um, we've done this kind of more manually and you kind of gotten a feel for some of this, but shown there ways to automate it more. It's just a it's a it's an intensive process to like there's comp doing this is a lot more infrastructure than doing like a random forest for instance. >> Yeah. >> Yeah. Two questions. Um, in terms of actual numbers, like what how long does it take for us to do a six-hour forecast to compare to CAM? Like what's the savings there? I think it well said it's 350 times >> 350 times >> faster. >> Yeah, we can do 480 simulated years per day with the emulator. uh at least the version in the paper compared with I think 14 simulated years per day for for CAM and and that that's also 480 simulator years per day on one 8100 GPU uh versus 10 14 simulator years per day on 10 DO nodes maybe 10 Shyen nodes but still uh like like it's a m a lot like a lot faster for a lot less compute so if you want to do large ensembles came later you can easily scale that And the second part is um so obviously we've seen six hour outputs and perhaps it was trained to do this on 6 hours and 12 hours. Um now you know if I want to do let's say long-term prediction with with cam I want to see what happens in 10 days. I'm guessing you can do that with cam data but can you trust what you get what what it gives you? Yeah, [clears throat] well that's what some of our slides are showing is like yeah we we only train out to 12 hours but it but it does seem to be picking up on teleconnections and other like structures in the data that have longer term uh that basically are slower signals. Uh and I think part of it is we have all we have we have a full set of vertical levels compared to where we only were sampling a subset of of the state of the vertical state. So, so we capture a lot more features and those seem to propagate through time really well. Um, the one the one thing where where there still seems to be some open question like like we added CO2 in a in a newer version of Camulator as a field. Uh, but the model does and it seems to pick up if you if your SSD and CO2 are consistent with each other. The it seems to pick up on the right global warning system, but they're they're inconsistent. If you hold one constant, let the other one go. It you you get some non-physical stuff going on. So, so there are there are some processes that that I wouldn't entirely trust just yet. Uh, especially if you're like [clears throat] interested in the radiative forcing effects and which was kind of an important important climate process. >> But there has been like green function work that's been done showing that it's actually kind of okay. >> I think maybe the last question is a different one. I think we don't know if it captures divergent trajectories in a chaotic vision. So it might not get an error growth right unless we're saying yeah it's not not not I think it's doable we know that from other models but that was not what intent of this particular >> yeah yeah this is more intent like more direct to climate time scales and and [clears throat] we are we are seeing issues where it it varies by the model some of them seem are are like hard to knock and like don't seem to have as much of the chaotic error growth and some have a lot but too much it really and they tend to blow up. Um and with with stocastic forcing we can we can get I think good ensemble diversity uh and with consistent like like being able to do it consistently through time you can kind of calibrate it out but but the like deterministic time steps definitely are underdoing chaotic the chaotic error growth of course there's also the counter argument around this is is chaotic error growth is a property of of a model rather than a like but how much is it a property of the underlying system. Um, so so that so that there there's some maybe not the best place to get into some of the debates on that, but but there are but that that like the the fact that the ML models are are kind of like have this sort of implicit conditioning of larger scale, medium scale, and smaller scale onto the system. Whereas like numerical models tend to only be local and their in their updates in terms of like spatial updates. um it kind of leads to to different sorts of evolution structures um for better or for worse. I'll just also mention um credit is exploring a variety of ensembling techniques for these emulators and I have some listed here on the slide including perturbing the latent space um using a variety of initial conditions scaps and diffusion methods >> steps within the AI >> yes >> is Donald contact with that >> yeah Donna Kar has been working on that he he does like a sort of Scabs, but not exactly scabs. That that seems to work late in space, right? Or where does it where is it implemented? Like if it's not in the physical model just trying to >> we have both. So we have scaps as scaps um and that's not fully that work is ongoing not fully tested yet and it has to do with the question if you can in the chaotic regime how we needed if we need to treat initial condition vertebrations initial condition perturbations or if we can use scaps to represent model error and initial condition uncertainty then this is some this is something we're working on actively and then the diffusion is is a different that I think John might might be the lead that's completely different. So I would think of it as a different >> stochastic scheme or different uncertainty scheme entirely. >> Yeah. Yeah. Yeah. The one John's working on is a is injecting [clears throat] noise into into the latent space of the [clears throat] of the model at different scales. >> Part of fenn know it's a different model. Right now you're doing it in WX form, but you can do it accumulate, but they both have the same underlying architecture. It's not there's nothing special. It's it's fairly model agnostic the way it's set up. You just have to find once you train a model, you just fine-tune it with a stochastic component. Uh and you can get and you can calibrate your model that way. And and you can also get a latent space where you can do interpolations between say ensemble members and your lat space and generate additional ensemble members. So So John's writing a paper up on this now. uh it there's some overlap with some of these techniques that like like uh so like ECW had the AIFS CRPS paper coming out late last year and then where where they basically do optimization on CRPS but then do they have lat space probabations to help generate the ensemble admittedly they also train this from scratch. Uh Google recently did did a version of this as well as Nvidia. Um and the big advantage of it is it's a lot faster to train than diffusion and and a lot faster to inference and it's easier to get a calibrated ensemble even with a small number of training ensemble members. So so and there and it's showing performance improvements and multiple groups have essentially done very similar things and they're all getting good result like significant improvements their forecast skill. So like like Google did ran their model in real time during hurricane season. And for a number of hurricanes, they were getting both improvements in track and intensity uh and were competitive with like the the consensus of all the other hurricane models. So, so there's there seems to be some it's doing some of the right things here basically. >> So, I'm going to take us back to the slides now. >> Um great discussion. I definitely think we should continue this um during the the question and answer, but I just want to finish up these slides here so we can we can get to that. Okay. So, everything that DJ's been talking about is the options within the credit platform. So, credit has integrated pre-processing for reanalysis, reforcast, and model data. It has a library of existing and new PyTorch neural network prediction architectures, scalable training and inference on ENAR HPC which is the biggest thing for me when I ran an emulator um analysis tools and plotting and then we've um recently deployed one of these models for forecasting in a weather um in a subseasonal forecasting challenge but also for handcasting and projections. So in terms of data sets they have data sets from A5, CAM, GES, KONUS 404 and CESM is also now there. Um some of the models we have Wexformer and Camulator are very similar architectures. Um Fushi um and Simudra are also included. Sudra is an ocean emulator. Um then there's the physics constraints and then these processing options so that ensemble generation is is there um vertical interpolation, regretting um diagnostics, all that type of stuff. Um this is an awesome platform that you can use. Um DJ is the lead of the miles group which is creating this credit platform. Um and if you have specific questions about that, I've used it. Can't say I'm an expert in it. Um, but I can help as along with DJ and, um, Charlie and, um, the the Miles team. So, um, in terms of how I used it, as someone who's never really worked in the emulator space, um, I was interested in subseasonal time scales. So, I wanted to create an emulator that incorporated, um, the ocean as a prognostic variable. So, it's input and output by the model and also land variables. So basically I took camulator but I trained it with SST soil moisture and surface temperature as input and output into the model. And this was a relatively simple um thing to do because the whole architecture was set up. There's a config file that you edit what your input and output var and your forcing variables are. So you basically just edit that, give it the associated files, and you're able to do all of this process with very little hands-on on the actual emulator portion. And then there's also um this whole section on grabbing GPUs and how much memory you need and all these things that can be that's all incorporated within the credit framework. So I was able to run sub CES emulator, which is what we're calling it. Um, but I'm willing to take names um for the subseasonal version of CES emulator. Um, and I am actually working with John on um ensemble generation with subc emulator. So, what we we're actually submitting this to the AI weather quest weekly. Um, well, I should say Charlie is really submitting this to the AI weather quest weekly. Thanks, Charlie. um and we have 341 members and we're getting this from the gas initial conditions and then we're also perturbing that 11 times each of those 11 times to get the 341 members using an the the typical S2S um perturbation method. Um but like we've already talked about there are other ways and we're going to explore um this latent space perturbation option um and maybe some others in terms of how how well this does at quantifying uncertainty in the forecast. Um, I don't know anything about this, but there's also a regional AI weather model that's been developed um to support fast dynamic downscaling and uh near real-time high resolution regional forecast. I'll direct you to Kyle Shaw and DJ for questions on this, but I also just wanted to let you know that this is also happening in the credit platform. Um, and then lastly, some ongoing challenges in the emulator space, very broad. How do we actually evaluate these emulators in a systematic way? Um to evaluate if they're even representing physical processes well um uh and doing this in a systematic approach. There's the fast versus slow time scale processes. Um the climate time on climate scales we have the ocean, we have the atmosphere, we have the stratosphere. These all happen at different time scales. and how to incorporate each of these time scales within your training um is an open question. I believe DJ is working on this in terms of um incorporating different um portions of the loss function for fast versus slow um time scales. And then there's this big problem of out of sample fidelity. If you don't train on a future warmer climate, can it actually represent a future warmer climate? And that's all I have. So