Creation of a WECC Storage Model in PSCAD Using FORTRAN (REPC, REEC and REGC)
Case Study
For more detail, figures and results - download the PDF
Download PDFIntroduction
Over the last few weeks I have been exploring using AI to develop sub-modules in PSCAD, and specifically to create a series of the Western Electricity Coordinating Council (WECC) models for a typical Battery Energy Storage System (BESS). The modules were created using a Claude Code MCP interface to PSCAD, and then directly using the AI to create the modules using FORTRAN code, rather than direct building using transfer functions and module wiring.
As with other posts, all the detail is in the PDF, and the below are just edited highlights.
Models and Relevance
The WECC models were developed for a number of reasons, primarily to ease deployment in simple RMS (positive sequence) simulation software, especially in cases where OEMs had either not developed a model in a particular package or were unwilling to release the details. The exercise built a model of a Plant Controller (REPC_C), Inverter Controller (REEC_C) and Generator (REGC_C).
Obviously these are all slightly simplified positive sequence models - although as REPC & REEC are control systems this matters less, the implementation of REGC is slightly less robust than a full EMT switching-level model. However, the aim of the exercise is very much about testing the AI ability to interface and build in PSCAD, rather than to produce full representations of a system. Particularly the PLL representation in the REGC model is necessarily simpler than reality.

Coding in FORTRAN
A big part of the exercise was choosing to code in FORTRAN. I am an old school engineer, and like to build up control systems block-by-block using transfer functions; this is fine for small to medium systems, but always takes some debugging and usually involves trying to create some workaround or other if a more complex transfer function is needed. Within PSCAD though it is possible to produce a submodule, with the required ports, and then just add the FORTRAN code directly.
I had spent some time teaching my local instance how to create sub-modules and ports previously, so this stage of the process was fairly easy and painless. The process was simple, I chose a series of PDF models of the various WECC controllers and the associated settings and then fed them into Claude, along with the standard parameterisation. Claude was able to recognise the image, decompose it into the appropriate transfer functions and then write the FORTRAN code.
Testing and Validating
As with all system models, but particularly code-based models, testing is of key importance as it is very easy to miss a function, invert a sign, forget to add a limit etc. An AI modelling something faces similar problems, especially if working off badly scanned PDF documents.

The fun part of this process, was to get Claude to actually design the test regime for each of the individual modules, and make sure it was testing all the functions robustly. Obviously the testing used in this experiment was fairly simple and not as rigorous as someone producing detailed models for use in equipment, or needing validation by a TSO, but the same general principle was followed. I had to set some of the boundaries for testing, such as strong grid, weak grid, which codes to follow etc, but the AI did the heavy lifting of specifying the test and tracing the step responses.




Interestingly, the AI picked up some odd results and came to me for guidance (as per my standing rules). The specific cases of interest, were a mix. Some were a few edge cases, whilst others were real problems and headaches I have seen in the wild:
- Problem with the Freeze mode of the inverter during FRT events (a well known issue)
- Problem with the Vmin settings during extended duration voltage dips to 85% for 180s (another well known issue)
- Problem with LVRT oscillation on a weak grid (known, but uncommon)
- Problems with some limit functions on the generator model (little bit obscure this one)
The FRT results were a bit questionable, but the general response behaviour was ok.
Summary
The overall report is attached, all generated by the AI, but with myself going through and pruning out some of the weeds and strange wording style Claude has a habit of adopting. The report provides a detailed narrative, scenarios, study cases and results for the individual components and then the overall system. As with all AI analysis, the actual model is largely irrelevant, what is impressive is the ability of the AI to carry out the analysis. What is interesting in this case compared to earlier works, is how autonomous the process was - it needed much less hand-holding, and tended to correct itself as it went. There were only a few odd results where I had to step in and confirm that they were as expected, or explain the behaviour being observed.