Category: Results

Posted on

First Visualization of the UVic Architecture

Our goal is to understand the composition of climate and ocean models to support their modularization and future development. Recently, we applied runtime monitoring on the MITgcm model. Based on our experience there, we applied the technique to the Earth System Climate Model (ESCM) of University of Victoria, Canada. Please be aware that these are very early results and may be erroneous.

The UVic model can be compiled with GNU Fortran (gfortran), but the current setup, we used, only produces a running executable with the Intel Fortran compiler (ifort). Fortunately, ifort support the same interface for runtime instrumentation as gfortran. Thus, we could apply the same probes in this context.

Based on this setup, we recorded 79 GB of binary monitoring data from a partial model run. We aim to have a complete run in future, but for the proof of concept, a partial run is sufficient. For our analysis we aimed to use the standard Kieker trace-analysis tool.

However, the Kieker trace-analysis tool uses call traces to reconstruct the deployed architecture. It is designed that way based on knowledge from web-based and service-oriented services. They have usually a small set of calls in a trace, triggered by an incoming event, message or request. In models, this is quite different. They are called once and run for a long time. Essentially, this results in one big trace. In our case 79 GB trace. This would not fit into memory, and even if, it would be very slow to process. Thus, we created a new architecture reconstruction tool based on another set of Kieker analysis stages. Utilizing this tool, we could generate our first component and operations graphs. The first component graph can be seen below.

UVic architecture based on Kieker monitoring data. Files are considered to be components.

We will continue our analysis to provide better readable graphs.

Posted on

Architecture Analysis of Climate Models based on Kieker Runtime Data

We are analyzing the architecture of climate and ocean models utilizing runtime monitoring data reflecting call traces. Currently, we are testing our technical approach based on the MITgcm and its set of prepared verification experiments including all tutorial setup.

Today we analyzed two experiments, namely tutorial_barotropic_gyre and tutorial_global_oce_biogeo. For the former, we derived components based on files. For the latter, we derived components based on the package and source code directory structure, namely, each MITgcm package represents one component and the main code block is represented by the BASE component.

Preliminary results can be seen in the following two figures:

Components based on files

As you can see, the file based components are quite numerous and result in a fast graph. In contrast the, package based component graph looks as follows.

Components based on packages and main source tree

In the latter graphic you can see cyclic dependencies between BASE and most components. This might be the result that BASE comprises of all non-package code files. Thus, a better separation in this area might be helpful. Still, the figure is much concise and understandable.

Due to technical issues, we cannot provide operation based images for both cases. There might be an error in the dot renderer.

Posted on

Experimenting with MITgcm

In our OceanDSL research project, we aim to produce Domain-Specific Languages (DSLs) for scientists and technicians to support and ease their work. We learned that through a set of interviews with them that every model uses special self-made tools and methods to configure, build and run models. This makes our effort complicated. Therefore, we need a model which is fairly simple to setup, but covers all typical steps in model setup. We choose MITgcm based on a recommendation of a collaborating scientist.

MITgcm is an earth model including ocean and atmosphere. Before we can use it as a case study in our model user and model developer scenarios, we need to make us familiar with the model.

As a first step, we aimed to play with the examples of the model. Therefore, we created a setup which can run directly on a Linux machine and one to be run in a docker container. We tested both setup with the tutorial examples of MITgcm. Based on the Barotropic Ocean Gyre we created an image of the result of the model run and a video showing intermediate results of the model in an animation.

The single images where generated using Octave (as a free Matlab replacement) and transformed into a video with Mencoder.

Barotropic tutorial model result for an rectangular ocean.
# Adjust the following path
addpath ADD-HERE-FULL-PATH-TO-THE-MITGCM-MATLAB-SCRIPTS

XC=rdmds('XC'); YC=rdmds('YC');
# Select a proper value. The start value is 0
Eta=rdmds('Eta',0);

contourf(XC/1000,YC/1000,Eta,[-.04:.01:.04]);
colorbar;
colormap((flipud(hot)));
set(gca,'XLim',[0 1200]);
set(gca,'YLim',[0 1200])

The script for the animation looks like this:

# Adjust the following path
addpath ADD-HERE-FULL-PATH-TO-THE-MITGCM-MATLAB-SCRIPTS
XC=rdmds('XC'); YC=rdmds('YC');

# The number of frames depend on your setup
for m = 0:60
  out=["out" num2str(m, "%04d") ".png"];
  # The multiplier depends on your setup
  Eta=rdmds('Eta',1296*m);

  hf = figure ("visible", "off");
  contourf(XC/1000,YC/1000,Eta,[-.04:.01:.04]);
  colorbar;
  colormap((flipud(hot)));
  set(gca,'XLim',[0 1200]);
  set(gca,'YLim',[0 1200]);
  print(hf, out, "-dpng "); 
endfor

Finally, the mencoder call looks like this: 

mencoder mf://out????.png -mf fps=2:type=png -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:trell -oac copy -o output.avi
Animation of the example model.

The setup is available at https://git.se.informatik.uni-kiel.de/oceandsl/case-study-mitgcm