diff --git a/.nojekyll b/.nojekyll
index 15d8054..39f43ee 100644
--- a/.nojekyll
+++ b/.nojekyll
@@ -1 +1 @@
-5e5d98d8
\ No newline at end of file
+9c434cdb
\ No newline at end of file
diff --git a/about.html b/about.html
index fc7f8e9..4f94427 100644
--- a/about.html
+++ b/about.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - About</title>
+<title>Data Assimilation docs - About</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -79,7 +79,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="./index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -159,7 +159,7 @@
     <h2 id="toc-title">On this page</h2>
    
   <ul>
-  <li><a href="#about-my-phd" id="toc-about-my-phd" class="nav-link active" data-scroll-target="#about-my-phd">About my PhD</a></li>
+  <li><a href="#hi" id="toc-hi" class="nav-link active" data-scroll-target="#hi">Hi!</a></li>
   </ul>
 <div class="toc-actions"><ul><li><a href="https://github.com/paocorrales/DA-documentation/edit/main/about.qmd" class="toc-action"><i class="bi bi-github"></i>Edit this page</a></li><li><a href="https://github.com/paocorrales/DA-documentation/issues/new/choose" class="toc-action"><i class="bi empty"></i>Report an issue</a></li></ul></div></nav>
     </div>
@@ -185,13 +185,13 @@ <h1 class="title">About</h1>
 </header>
 
 
-<p>This guide is a compilation of many tools scripts, pieces of code and routines that I used during my PhD. As the name says, everything goes around assimilating observations using the GSI system. I spent a lot of time working with the conventional and Radiance observations so you will find a comprehensive tutorial and documentation on how to assimilate these types of observations. This includes the processing of the observations, how to configure the system and all the quality control steps GSI performs during the assimilation process.</p>
-<p>Sometimes you will find everything inside the website and sometimes you will need to go to a specific repository to get the code or the data associated with the the specific topic. And while I tried to be mindful during my PhD at commenting and documenting everything along the way I’m sure that there are gaps and missing pieces. If you find anything that can be improved please open an issue in the repository of this website and contribute to making this guide better.</p>
-<p>Many of these tools come from different sources. Sometimes someone else wrote the code and I adapted it to my specific needs, sometimes I wrote the code from scratch. So it’s important to read the license note in each section so you know who created that code and in which way you can use it.</p>
-<section id="about-my-phd" class="level2">
-<h2 class="anchored" data-anchor-id="about-my-phd">About my PhD</h2>
-<p>The main goal of may research was to applied data assimilation techniques to improve short-term forecasts of severe events in Argentina. In particular, the research focuses on data assimilation of observations from automatic stations and radiances from polar and geostationary satellites. You can read the final dissertation (in Spanish) <a href="https://paocorrales.github.io/Tesis_doctorado/">here</a>.</p>
+<section id="hi" class="level2">
+<h2 class="anchored" data-anchor-id="hi">Hi!</h2>
+<p>I’m Pao Corrales and I have a PhD in Atmospheric Science! The main goal of my research was to applied data assimilation techniques to improve short-term forecasts of severe events in Argentina. In particular, the research focuses on data assimilation of observations from automatic stations and radiances from polar and geostationary satellites. You can read the final dissertation (in Spanish) <a href="https://paocorrales.github.io/Tesis_doctorado/">here</a>.</p>
 <p>I worked in the <a href="https://www.cima.fcen.uba.ar/index.php">Centro de Investigaciones del Mar y la Atmósfera</a> (CIMA), for that reason you may find mentions to Hydra or Yakaira, their HPC and a server I used a lot.</p>
+<p>This guide is a compilation of many tools, scripts, pieces of code and routines that I used during my PhD. As the name says, everything goes around assimilating observations using the GSI system. I spent a lot of time working with the conventional and Radiance observations so you will find a comprehensive tutorial and documentation on how to assimilate these types of observations. This includes the processing of the observations, how to configure the system and all the quality control steps GSI performs during the assimilation process.</p>
+<p>Sometimes you will find everything inside the website and sometimes you will need to go to a specific repository to get the code or the data associated with the the specific topic. And while I tried to be mindful during my PhD at commenting and documenting everything along the way I’m sure that there are gaps and missing pieces. If you find anything that can be improved please <a href="./contribute.html">open an issue in the repository</a> of this website and contribute to make this guide better.</p>
+<p>Many of these tools come from different sources. Sometimes someone else wrote the code and I adapted it to my specific needs, sometimes I wrote the code from scratch. So it’s important to read the license note in each section so you know who created that code and in which way you can use it.</p>
 
 
 </section>
diff --git a/content/gsi/01-gsi.html b/content/gsi/01-gsi.html
index 0275954..07f1e4f 100644
--- a/content/gsi/01-gsi.html
+++ b/content/gsi/01-gsi.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - The GSI assimilation system</title>
+<title>Data Assimilation docs - The GSI assimilation system</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -128,7 +128,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="../../index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -242,10 +242,10 @@ <h1 class="title">The GSI assimilation system</h1>
 
 
 <p>The GSI (Gridpoint Statistical Interpolation) System, is a state-of-the-art data assimilation system initially developed by the Environmental Modeling Center at NCEP. It was designed as a traditional 3DVAR system applied in the gridpoint space of models to facilitate the implementation of inhomogeneous anisotropic covariances <span class="citation" data-cites="wu2002 purser2003a purser2003">(<a href="#ref-wu2002" role="doc-biblioref">Wu, Purser, and Parrish 2002</a>; <a href="#ref-purser2003a" role="doc-biblioref">Purser et al. 2003b</a>, <a href="#ref-purser2003" role="doc-biblioref">2003a</a>)</span>. It is designed to run on various computational platforms, create analyses for different numerical forecast models, and remain flexible enough to handle future scientific developments, such as the use of new observation types, improved data selection, and new state variables <span class="citation" data-cites="kleist2009">(<a href="#ref-kleist2009" role="doc-biblioref">Kleist et al. 2009</a>)</span>.</p>
-<p>The- 3DVAR system replaced the NCEP regional grid-point operational analysis system by the North American Mesoscale Prediction System (NAM) in 2006 and the <em>Spectral Statistical Interpolation</em> (SSI) global analysis system used to generate <em>Global Forecast System</em> (GFS) initial conditions in 2007 <span class="citation" data-cites="kleist2009">(<a href="#ref-kleist2009" role="doc-biblioref">Kleist et al. 2009</a>)</span>. In recent years, GSI has evolved to include various data assimilation techniques for multiple operational applications, including 2DVAR [e.g., the <em>Real-Time Mesoscale Analysis</em> (RTMA) system; <span class="citation" data-cites="pondeca2011">Pondeca et al. (<a href="#ref-pondeca2011" role="doc-biblioref">2011</a>)</span>], the hybrid EnVar technique (e.g., data assimilation systems for the GFS, the <em>Rapid Refresh system</em> (RAP), the NAM, the HWRF, etc. ), and 4DVAR [e.g., the data assimilation system for NASA’s Goddard Earth Observing System, version 5 (GEOS-5); <span class="citation" data-cites="zhu2008">Zhu and Gelaro (<a href="#ref-zhu2008" role="doc-biblioref">2008</a>)</span>]. GSI also includes a hybrid 4D-EnVar approach that is currently used for GFS generation.</p>
+<p>The 3DVAR system replaced the NCEP regional grid-point operational analysis system by the North American Mesoscale Prediction System (NAM) in 2006 and the <em>Spectral Statistical Interpolation</em> (SSI) global analysis system used to generate <em>Global Forecast System</em> (GFS) initial conditions in 2007 <span class="citation" data-cites="kleist2009">(<a href="#ref-kleist2009" role="doc-biblioref">Kleist et al. 2009</a>)</span>. In recent years, GSI has evolved to include various data assimilation techniques for multiple operational applications, including 2DVAR [e.g., the <em>Real-Time Mesoscale Analysis</em> (RTMA) system; <span class="citation" data-cites="pondeca2011">Pondeca et al. (<a href="#ref-pondeca2011" role="doc-biblioref">2011</a>)</span>], the hybrid EnVar technique (e.g., data assimilation systems for the GFS, the <em>Rapid Refresh system</em> (RAP), the NAM, the HWRF, etc. ), and 4DVAR [e.g., the data assimilation system for NASA’s Goddard Earth Observing System, version 5 (GEOS-5); <span class="citation" data-cites="zhu2008">Zhu and Gelaro (<a href="#ref-zhu2008" role="doc-biblioref">2008</a>)</span>]. GSI also includes a hybrid 4D-EnVar approach that is currently used for GFS generation.</p>
 <p>In addition to the development of hybrid techniques, GSI allows the use of ensemble assimilation methods. To achieve this, it uses the same observation operator as the variational methods to compare the preliminary field or background with the observations. In this way the exhaustive quality controls developed for variational methods are also applied in ensemble assimilation methods. The EnKF code was developed by the Earth System Research Lab (ESRL) of the National Oceanic and Atmospheric Administration (NOAA) in collaboration with the scientific community. It contains two different algorithms for calculating the analysis increment, the serial Ensemble Square Root Filter <span class="citation" data-cites="whitaker2002">(EnSRF, <a href="#ref-whitaker2002" role="doc-biblioref">Whitaker and Hamill 2002</a>)</span> and the LETKF <span class="citation" data-cites="hunt2007">(<a href="#ref-hunt2007" role="doc-biblioref">Hunt, Kostelich, and Szunyogh 2007</a>)</span> contributed by Yoichiro Ota of the Japan Meteorological Agency (JMA).</p>
-<p>To reduce the impact of spurious covariances on the increment applied to the analysis, ensemble systems apply a localization to the covariance matrix of the errors of the observations <span class="math inline">\(R\)</span> in both the horizontal and vertical directions. GSI uses a polynomial of order 5 to reduce the impact of each observation gradually until a limiting distance is reached at which the impact is zero. The vertical location scale is defined in terms of the logarithm of the pressure and the horizontal scale is usually defined in kilometers. These parameters are important in obtaining a good analysis and depend on factors such as the size of the ensemble and the resolution of the model.</p>
-<p>GSI uses the Community Radiative Transfer Model <span class="citation" data-cites="liu2008">(CRTM, <a href="#ref-liu2008" role="doc-biblioref">Liu et al. 2008</a>)</span> as an operator for the radiance observations that calculates the brightness temperature simulated by the model in order to compare it with satellite sensor observations. GSI also implements a bias correction algorithm for the satellite radiance observations. The preliminary field estimate with the CRMT is compared with the radiance observations to obtain the innovation. This innovation is then used to calculate a bias that is applied to an updated innovation. This process can be repeated several times until the innovation and the bias correction coefficients converge.</p>
+<p>To reduce the impact of spurious covariances on the increment applied to the analysis, ensemble systems apply a localization to the covariance matrix of the errors of the observations <span class="math inline">\(R\)</span> in both the horizontal and vertical directions. GSI uses a polynomial of order 5 to reduce the impact of each observation gradually until a limiting distance is reached at which the impact is zero. The vertical localization scale is defined in terms of the logarithm of the pressure and the horizontal scale is usually defined in kilometers. These parameters are important in obtaining a good analysis and depend on factors such as the size of the ensemble and the resolution of the model.</p>
+<p>GSI uses the Community Radiative Transfer Model <span class="citation" data-cites="liu2008">(CRTM, <a href="#ref-liu2008" role="doc-biblioref">Liu et al. 2008</a>)</span> as an operator for the radiance observations that calculates the brightness temperature simulated by the model in order to compare it with satellite observations. GSI also implements a bias correction algorithm for the satellite radiance observations. The preliminary field estimated with CRMT is compared with the radiance observations to obtain the innovation. This innovation is then used to calculate a bias that is then applied to an updated innovation. This process can be repeated several times until the innovation and the bias correction coefficients converge.</p>
 <section id="available-observations-for-assimilation" class="level2">
 <h2 class="anchored" data-anchor-id="available-observations-for-assimilation">Available observations for assimilation</h2>
 <p>Here is the list of observations that can be assimilated by GSI. In bold are the observations for with I have experience and/or the ones <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3">I’ve adapted the code for it</a>.</p>
@@ -321,7 +321,7 @@ <h3 class="anchored" data-anchor-id="other-observations">Other observations</h3>
 </section>
 <section id="running-gsi" class="level2">
 <h2 class="anchored" data-anchor-id="running-gsi">Running GSI</h2>
-<p>Every assimilation cycle starts with the background, a forecast generated using a numerical model (WRF-ARW for this guide), that was initialized from previous analysis and observations (in bufr format) that enters the GSI system. GSI will also need “fixed” files with information about the observations. This files define which observations are going to be assimilated, they errors and quality control options.</p>
+<p>Every assimilation cycle starts with the background, a forecast generated using a numerical model (WRF-ARW for this guide), that was initialized from previous analysis and observations (in bufr format) that enters the GSI system. GSI will also need “fixed” files with information about the observations. This “fix” files define which observations are going to be assimilated, they errors and quality control options.</p>
 <div class="quarto-figure quarto-figure-center">
 <figure class="figure">
 <p><img src="img/cycle_diagram.png" class="img-fluid figure-img" alt="Diagram that shows a cycle. First the background (forecasts generated using a numerical model, WRF-ARW, initialized from previous analysis) and Observations (from bufr files) enters the GSI system. Inside the system, the Observation Operator takes care of the quality control and bias correction and then calculates the innovation and generates the diag files. Then the ENKF part calculates the update appling the innovation to the background to generate the analysis. The analysis is used to create a new background to star the cycle again"></p>
@@ -340,8 +340,8 @@ <h2 class="anchored" data-anchor-id="running-gsi">Running GSI</h2>
 <li>WRF-Chem GOCART input fields with NetCDF format</li>
 <li>CMAQ binary file</li>
 </ul>
-<p>And the official tutorials are a good starting point to grasp the use of this options.</p>
-<p>GSI can also be run <em>without observations</em> to test the code, this is with a single synthetic observation defined in the SINGLEOB_TEST section in the namelist.</p>
+<p>And the <a href="https://dtcenter.org/community-code/gridpoint-statistical-interpolation-gsi/gsi-tutorial-online">official tutorials in the DTCenter webpage</a> are a good starting point to grasp the use of this options.</p>
+<p>GSI can also be run <em>without observations</em> to test the code, this is with a single synthetic observation defined in the SINGLEOB_TEST section in the gsi namelist. Another thing to try at the beginning.</p>
 <p>The fixed files are located in the <code>fix/</code> folder and includes statistic files, configuration files, bias correction files, and CRTM coefficient files<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>. The information of the configuration files is saved in the output files after running GSI.</p>
 <table class="table">
 <colgroup>
@@ -379,32 +379,32 @@ <h2 class="anchored" data-anchor-id="running-gsi">Running GSI</h2>
 </tr>
 <tr class="odd">
 <td>satinfo</td>
-<td>satellite channel information file</td>
+<td>Satellite channel information file</td>
 <td>global_satinfo.txt</td>
 </tr>
 <tr class="even">
 <td>pcpinfo</td>
-<td>precipitation rate observation information file</td>
+<td>Precipitation rate observation information file</td>
 <td>global_pcpinfo.txt</td>
 </tr>
 <tr class="odd">
 <td>ozinfo</td>
-<td>ozone observation information file</td>
+<td>Ozone observation information file</td>
 <td>global_ozinfo.txt</td>
 </tr>
 <tr class="even">
 <td>satbias_angle</td>
-<td>satellite scan angle dependent bias correction file</td>
+<td>Satellite scan angle dependent bias correction file</td>
 <td>global_satangbias.txt</td>
 </tr>
 <tr class="odd">
 <td>satbias_in</td>
-<td>satellite mass bias correction coefficient file</td>
+<td>Satellite mass bias correction coefficient file</td>
 <td>sample.satbias</td>
 </tr>
 <tr class="even">
 <td>satbias_in</td>
-<td>combined satellite angle dependent and mass bias correction coefficient file</td>
+<td>Combined satellite angle dependent and mass bias correction coefficient file</td>
 <td>gdas1.t00z.abias.new</td>
 </tr>
 </tbody>
@@ -412,7 +412,7 @@ <h2 class="anchored" data-anchor-id="running-gsi">Running GSI</h2>
 </section>
 <section id="about-the-gsi-code" class="level2">
 <h2 class="anchored" data-anchor-id="about-the-gsi-code">About the GSI code</h2>
-<p>GSI is writen in fortran and the code is separated in more than 5 hundred files. While GSI has 2 good user guides, not everything is documented and sometimes you will need to read the code.</p>
+<p>GSI is written in fortran and the code is separated in more than 5 hundred files. While GSI has <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3/tree/main/docs">2 good user guides</a>, not everything is documented and sometimes you will need to read the code.</p>
 <p>To swim around the code I found the <code>grep -r "key word"</code> command very useful. Each file and subroutine inside it has a header with information about what it does, changes and input and output arguments. It’s worth mentioning a few key files:</p>
 <ul>
 <li><code>gsimain.f90</code> and <code>gsimod.f90</code> are the main files that control the system. <code>gsimain.f90</code> has a list off code errors and the possible cause.</li>
diff --git a/content/gsi/02-convencionals.html b/content/gsi/02-convencionals.html
index 5943037..80d75b1 100644
--- a/content/gsi/02-convencionals.html
+++ b/content/gsi/02-convencionals.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - Assimilating Conventional Observations</title>
+<title>Data Assimilation docs - Assimilating Conventional Observations</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -142,7 +142,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="../../index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -251,10 +251,10 @@ <h1 class="title">Assimilating Conventional Observations</h1>
 
 <p>Conventional observations are assimilated from PREPBUFR files. NCEP ADP Global Upper Air and Surface Weather Observations (PREPBUFR format) are composed of a global set of surface and upper air reports operationally collected by the National Centers for Environmental Prediction (NCEP). These include land surface, marine surface, radiosonde, pibal and aircraft reports from the Global Telecommunications System (GTS), profiler and US radar derived winds, SSM/I oceanic winds and TCW retrievals, and satellite wind data from the National Environmental Satellite Data and Information Service (NESDIS). The reports can include pressure, geopotential height, temperature, dew point temperature, wind direction and speed <span class="citation" data-cites="cisl_rda_ds337.0">[@cisl_rda_ds337.0]</span>.</p>
 <p>While the PREPBUFR includes wind derived from satellite observations, GSI ignores this observations and uses the ones provided by the specific bufr file <code>gdas.t00z.satwnd.tm00.bufr_d</code>.</p>
-<p>PREPBUFR files usually contains observations from a 6 to 12 h window and can be modify using FORTRAN routines provided with the GSI code (see <code>util/bufr_tools</code> in the GSI source code folder). You can also create your own bufr file or add new observation to an existing bufr file (see <a href="../../content/observations/01-bufr.html">Working with bufr files</a>).</p>
+<p>PREPBUFR files usually contains observations from a 6 to 12 h window and can be modify using FORTRAN routines provided with the GSI code (see <code>util/bufr_tools</code> in the <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3">GSI source code folder</a>). You can also create your own bufr file or add new observation to an existing bufr file (see <a href="../../content/observations/01-bufr.html">Working with bufr files</a>).</p>
 <section id="controlling-which-observations-are-assimilated" class="level3">
 <h3 class="anchored" data-anchor-id="controlling-which-observations-are-assimilated">Controlling which observations are assimilated</h3>
-<p>The assimilation of conventional observations is controlled with the <code>convinfo</code> file. Let’s check the <code>global_convinfo.txt</code> file we get as an example:</p>
+<p>The assimilation of conventional observations is controlled with the <code>convinfo</code> file. Let’s check the <code>global_convinfo.txt</code> file we get as an example in the <code>fix</code> folder:</p>
 <div class="sourceCode" id="cb1"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ot">! </span><span class="ex">otype</span>   = observation type <span class="er">(</span><span class="ex">a7,</span> t, uv, q, etc.<span class="kw">)</span></span>
 <span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a><span class="ot">! </span><span class="bu">type</span>    = prepbufr observation type <span class="er">(</span><span class="cf">if</span> <span class="ex">available</span><span class="kw">)</span></span>
 <span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a><span class="ot">! </span><span class="ex">sub</span>     = prepbufr subtype <span class="er">(</span><span class="ex">not</span> yet available<span class="kw">)</span></span>
@@ -281,14 +281,14 @@ <h3 class="anchored" data-anchor-id="controlling-which-observations-are-assimila
 <span id="cb1-24"><a href="#cb1-24" aria-hidden="true" tabindex="-1"></a> <span class="fu">ps</span>       180    01   1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 <p>The head of the file explains the content of each column but there are a few more things to add:</p>
 <ul>
-<li>type: this is defined by the bufr tables, particular <a href="https://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_2.htm">Table 2</a>. It is worth checking this table as includes information about which observations are assimilated in GFS, errors asociated to specific instruments and other details.</li>
+<li>type: this is defined by the bufr tables, particular <a href="https://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_2.htm">Table 2</a>. It is worth checking this table as includes information about which observations are assimilated in GFS, errors associated to specific instruments and other details.</li>
 <li>twindow: while the assimilation window is defined in the gsi namalist, it is possible to control an assimilation window for specific observations. This is useful if, for example the assimilation window is 3 h and you want to assimilate temperature in a 1h window.</li>
 </ul>
-<p>In general you only change the <em>isue</em> column to assimilate or not a type of observation and maybe just maybe the <em>gross</em>, <em>ermax</em>, and <em>ermin</em> parameters if you want to modify the quality control of the observations.</p>
+<p>In general you only change the <em>iuse</em> column to assimilate or not a type of observation and maybe just maybe the <em>gross</em>, <em>ermax</em>, and <em>ermin</em> parameters if you want to modify the quality control of the observations.</p>
 </section>
 <section id="observation-errors-and-quality-control" class="level3">
 <h3 class="anchored" data-anchor-id="observation-errors-and-quality-control">Observation errors and quality control</h3>
-<p>For <strong>regional assimilation</strong> GSI uses an error table located in the <code>errtable</code> file that you’ll find in the <code>./fix</code> folder under the name <code>prepobs_errtable.global</code> (it is confusing that the table for regional errors in in a file called global). Here is a small example of the content of the file for observations from surface stations.</p>
+<p>For <strong>regional assimilation</strong> GSI uses an error table located in the <code>errtable</code> file that you’ll find in the <code>./fix</code> folder under the name <code>prepobs_errtable.global</code> (yes, it is confusing that the table for regional errors in in a file called global). Here is a small example of the content of the file for observations from surface stations.</p>
 <div class="sourceCode" id="cb2"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ex">181</span> OBSERVATION TYPE</span>
 <span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a>  <span class="ex">0.11000E+04</span> 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10</span>
 <span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a>  <span class="ex">0.10500E+04</span> 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10</span>
@@ -345,9 +345,9 @@ <h3 class="anchored" data-anchor-id="observation-errors-and-quality-control">Obs
 <p>So column 1 define the pressure level associated to the errors for each variable in columns 2 to 6. In the <code>errtable</code> a <code>0.10000E+10</code> is a <code>NA</code>.</p>
 <p>GSI will perform a quality control for each observation. In general terms this involves a gross check and specific controls depending on the type of observation.</p>
 <p>For the gross check, GSI first calculates a ratio:</p>
-<p><span class="math display">\[ ratio = (obs - bk)/max(ermin, min(ermax, obserror)) \]</span> The main error parameters are controlled by the <code>convinfo</code> file. The <code>obserror</code> is the observation error defined in the prepbufr file for each observation as a result to the quality control perform while generating that file.</p>
+<p><span class="math display">\[ ratio = (obs - bk)/max(ermin, min(ermax, obserror)) \]</span> The main error parameters are controlled by the <code>convinfo</code> file. The <code>obserror</code> is the observation error defined in the prepbufr file for each observation plus information in the <code>prepobs_errtable</code>.</p>
 <p>If <span class="math inline">\(ration &gt; gross\)</span> the observation is rejected.</p>
-<p>Other piece of information used during the quality control is the quality control flag that is included in the prepbufr file a part if it quality control process. The possible values for conventional observations are:</p>
+<p>Other piece of information used during the quality control is the quality control flag that is included in the prepbufr file a part if it quality control process performed by NCEP. The possible values for conventional observations are:</p>
 <table class="table">
 <colgroup>
 <col style="width: 44%">
diff --git a/content/gsi/03-radiances.html b/content/gsi/03-radiances.html
index a0164bb..f237b9e 100644
--- a/content/gsi/03-radiances.html
+++ b/content/gsi/03-radiances.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - Assimilating Radiance Observations</title>
+<title>Data Assimilation docs - Assimilating Radiance Observations</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -162,7 +162,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="../../index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -276,11 +276,11 @@ <h1 class="title">Assimilating Radiance Observations</h1>
 </header>
 
 
-<p>Assimilating radiance observations is more complicated than assimilating conventional observations as radiances are not state variables. We need a observation operator to transform the model variables to radiances. GSI uses the Community Radiative Transfer Model <span class="citation" data-cites="liu2008">(CRTM, <a href="#ref-liu2008" role="doc-biblioref">Liu et al. 2008</a>)</span> as an operator of the radiance observations that calculates the brightness temperature simulated by the model in order to compare it with the observations from satellite sensors.</p>
+<p>Assimilating radiance observations is more complicated than assimilating conventional observations as radiances are not state variables. We need a observation operator to transform the model variables to brightness temperature. GSI uses the Community Radiative Transfer Model <span class="citation" data-cites="liu2008">(CRTM, <a href="#ref-liu2008" role="doc-biblioref">Liu et al. 2008</a>)</span> as an operator of the radiance observations that calculates the brightness temperature simulated by the model in order to compare it with the observations from satellite sensors.</p>
 <section id="the-crtm-radiative-transfer-model" class="level2">
 <h2 class="anchored" data-anchor-id="the-crtm-radiative-transfer-model">The CRTM radiative transfer model</h2>
-<p>The CRTM is a fast radiative transfer model that was jointly developed by the <em>NOAA Center for Satellite Applications and Research</em> and the <em>Joint Center for Satellite Data Assimilation</em> (JCSDA). It is a model widely used by the remote sensing community as it is open source and publicly available. In addition, it is used for satellite instrument calibration <span class="citation" data-cites="weng2013 iacovazzi2020 crews2021">(<a href="#ref-weng2013" role="doc-biblioref">Weng et al. 2013</a>; <a href="#ref-iacovazzi2020" role="doc-biblioref">Iacovazzi et al. 2020</a>; <a href="#ref-crews2021" role="doc-biblioref">Crews et al. 2021</a>)</span>, and in turn to generate retrievals from satellite observations <span class="citation" data-cites="boukabara2011 hu2019 hu2021">(<a href="#ref-boukabara2011" role="doc-biblioref">Boukabara et al. 2011</a>; <a href="#ref-hu2019" role="doc-biblioref">H. Hu et al. 2019</a>; <a href="#ref-hu2021" role="doc-biblioref">H. Hu and Han 2021</a>)</span>. It is also used as an operator of observations as part of the assimilation of satellite radiances <span class="citation" data-cites="tong2020 barton2021">(<a href="#ref-tong2020" role="doc-biblioref">Tong et al. 2020</a>; <a href="#ref-barton2021" role="doc-biblioref">Barton et al. 2021</a>)</span>.</p>
-<p>The CRTM is capable of simulating microwave, infrared and visible radiances, under clear and cloudy sky conditions, using atmospheric profiles of pressure, temperature, humidity and other species such as ozone. Recently <span class="citation" data-cites="cutraro2021">Cutraro, Galligani, and Skabar (<a href="#ref-cutraro2021" role="doc-biblioref">2021</a>)</span> evaluated their takeoff in the region with good results in simulating GOES-16 observations.</p>
+<p>The CRTM is a fast radiative transfer model that was jointly developed by the <em>NOAA Center for Satellite Applications and Research</em> and the <em>Joint Center for Satellite Data Assimilation</em> (JCSDA). It is a model widely used by the remote sensing community as it is open source and publicly available. In addition, it is used for satellite instrument calibration <span class="citation" data-cites="weng2013 iacovazzi2020 crews2021">(<a href="#ref-weng2013" role="doc-biblioref">Weng et al. 2013</a>; <a href="#ref-iacovazzi2020" role="doc-biblioref">Iacovazzi et al. 2020</a>; <a href="#ref-crews2021" role="doc-biblioref">Crews et al. 2021</a>)</span>, and to generate retrievals from satellite observations <span class="citation" data-cites="boukabara2011 hu2019 hu2021">(<a href="#ref-boukabara2011" role="doc-biblioref">Boukabara et al. 2011</a>; <a href="#ref-hu2019" role="doc-biblioref">H. Hu et al. 2019</a>; <a href="#ref-hu2021" role="doc-biblioref">H. Hu and Han 2021</a>)</span>. It is also used as an operator of observations as part of the assimilation of satellite radiances <span class="citation" data-cites="tong2020 barton2021">(<a href="#ref-tong2020" role="doc-biblioref">Tong et al. 2020</a>; <a href="#ref-barton2021" role="doc-biblioref">Barton et al. 2021</a>)</span>.</p>
+<p>The CRTM is capable of simulating microwave, infrared and visible radiances, under clear and cloudy sky conditions, using atmospheric profiles of pressure, temperature, humidity and other species such as ozone. Recently <span class="citation" data-cites="cutraro2021">Cutraro, Galligani, and Skabar (<a href="#ref-cutraro2021" role="doc-biblioref">2021</a>)</span> evaluated their use in Argentina with good results in simulating GOES-16 observations.</p>
 <p>CRTM is a sensor-oriented radiative transfer model, i.e.&nbsp;it contains pre-calculated parameterizations and coefficient tables specifically for operational sensors. It includes modules that calculate thermal radiation from gaseous absorption, absorption and scattering by aerosols and clouds, and emission and reflection of radiation by the Earth’s surface. The inputs of CRTM include atmospheric state variables, e.g., temperature, water vapor, pressure, and ozone concentration in user-defined layers, and surface state variables and parameters, including emissivity, surface temperature, and wind.</p>
 <p>CRTM is capable to simulate satellite observations from the state of the atmosphere. This is necessary during the assimilation process but is also used to verify the accuracy and errors of radiance observations.</p>
 <p>The necessary calculations to simulate observations has a very high computational cost as it requires transposing a high dimensional matrix and the minimization of a cost function. This <span class="math inline">\(K^{*}\)</span> matrix is constructed from the partial derivatives of the radiances with respect to geophysical parameters. CRTM performs these calculations very quickly so it can be used in operational contexts.</p>
@@ -307,7 +307,7 @@ <h2 class="anchored" data-anchor-id="specific-configuration">Specific configurat
 <span id="cb1-15"><a href="#cb1-15" aria-hidden="true" tabindex="-1"></a> <span class="ex">amsua_n15</span>              14  <span class="at">-1</span>    2.000    2.000    4.500   10.000    0.000     <span class="at">-2</span>      1     <span class="at">-1</span></span>
 <span id="cb1-16"><a href="#cb1-16" aria-hidden="true" tabindex="-1"></a> <span class="ex">amsua_n15</span>              15   1    3.500   18.000    4.500   10.000    0.000     <span class="at">-2</span>      1     <span class="at">-1</span></span>
 <span id="cb1-17"><a href="#cb1-17" aria-hidden="true" tabindex="-1"></a> <span class="ex">hirs3_n17</span>               1  <span class="at">-1</span>    2.000    0.000    4.500   10.000    0.000     <span class="at">-1</span>     <span class="at">-1</span>     <span class="at">-1</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
-<p>The file includes a line for each sensor/satellite and each channel (chan). Usually you will change the <code>iuse</code> and <code>error</code> columns to configure the assimilation of each channel. The options for <code>iuse</code> are:</p>
+<p>The file includes a line for each sensor/satellite and each channel (<code>chan</code>). Usually you will change the <code>iuse</code> and <code>error</code> columns to configure the assimilation of each channel. The options for <code>iuse</code> are:</p>
 <ul>
 <li>-2 do not use</li>
 <li>-1 monitor if diagnostics produced</li>
@@ -323,9 +323,9 @@ <h2 class="anchored" data-anchor-id="specific-configuration">Specific configurat
 <p><strong>GSI namelist</strong></p>
 <table class="table">
 <colgroup>
-<col style="width: 19%">
-<col style="width: 61%">
-<col style="width: 19%">
+<col style="width: 11%">
+<col style="width: 80%">
+<col style="width: 8%">
 </colgroup>
 <thead>
 <tr class="header">
@@ -365,11 +365,10 @@ <h2 class="anchored" data-anchor-id="specific-configuration">Specific configurat
 <p>This namelist will also includes a list with the type of observations and the name of the bufr file for each one (<code>dfile</code>).</p>
 <p><strong>ENKF namelist</strong></p>
 <table class="table">
-<caption>This namelist will also includes a list with the type of observations and the name of each one inside GSI. For example <code>amsua_n15</code> represent the observations of the AMSU-A sensor on board NOAA-15.</caption>
 <colgroup>
-<col style="width: 16%">
-<col style="width: 66%">
-<col style="width: 16%">
+<col style="width: 10%">
+<col style="width: 77%">
+<col style="width: 11%">
 </colgroup>
 <thead>
 <tr class="header">
@@ -406,6 +405,7 @@ <h2 class="anchored" data-anchor-id="specific-configuration">Specific configurat
 </tr>
 </tbody>
 </table>
+<p>This namelist will also includes a list with the type of observations and the name of each one inside GSI. For example <code>amsua_n15</code> represent the observations of the AMSU-A sensor on board NOAA-15.</p>
 </section>
 <section id="observation-errors-and-quality-control" class="level2">
 <h2 class="anchored" data-anchor-id="observation-errors-and-quality-control">Observation errors and quality control</h2>
@@ -490,7 +490,8 @@ <h3 class="anchored" data-anchor-id="sec-bias-correction">Bias correction</h3>
 </section>
 <section id="cloud-detection" class="level3">
 <h3 class="anchored" data-anchor-id="cloud-detection">Cloud detection</h3>
-<p>The cloud pixel detection methodology depends on the wavelength of the observations. For microwave radiances, potentially cloud-contaminated observations are detected using scattering and Liquid Water Path (LWP) indices calculated from differences between different channels of each sensor <span class="citation" data-cites="weston2019 zhu2016">(<a href="#ref-weston2019" role="doc-biblioref">Weston et al. 2019</a>; <a href="#ref-zhu2016" role="doc-biblioref">Zhu et al. 2016</a>)</span>. For infrared channels, cloud contaminated observations are detected using the transmittance profile calculated by the CRTM model. In addition, GSI checks the difference between the observations and the simulated brightness temperature to detect cloudy pixels. A particular case is the ABI observations since the cloud mask (level 2 product) available at the same resolution as the observations is used. This cloud mask is generated by combining information from 8 channels of the ABI sensor from the spatial and temporal point of view.</p>
+<p>The cloud pixel detection methodology depends on the wavelength of the observations. For microwave radiances, potentially cloud-contaminated observations are detected using scattering and Liquid Water Path (LWP) indices calculated from differences between different channels of each sensor <span class="citation" data-cites="weston2019 zhu2016">(<a href="#ref-weston2019" role="doc-biblioref">Weston et al. 2019</a>; <a href="#ref-zhu2016" role="doc-biblioref">Zhu et al. 2016</a>)</span>. For infrared channels, cloud contaminated observations are detected using the transmittance profile calculated by the CRTM model. In addition, GSI checks the difference between the observations and the simulated brightness temperature to detect cloudy pixels.</p>
+<p>A particular case is the ABI observations since the cloud mask (level 2 product) available at the same resolution as the observations is used. This cloud mask is generated by combining information from 8 channels of the ABI sensor from the spatial and temporal point of view.</p>
 </section>
 <section id="other-quality-controls" class="level3">
 <h3 class="anchored" data-anchor-id="other-quality-controls">Other quality controls</h3>
diff --git a/content/gsi/04-diagfiles.html b/content/gsi/04-diagfiles.html
index 4bb05e2..5db81d9 100644
--- a/content/gsi/04-diagfiles.html
+++ b/content/gsi/04-diagfiles.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - Undestanding diag(nostic) files</title>
+<title>Data Assimilation docs - Undestanding diag(nostic) files</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -113,7 +113,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="../../index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -223,8 +223,8 @@ <h1 class="title">Undestanding diag(nostic) files</h1>
 
 <p>The <code>diag_&lt;obs&gt;</code> files save the key information of how the observations where assimilated (with the variational method) or are going to be assimilated (using Kalman Filter), including the innovation (observation minus background), observation values, observation error and adjusted observation error, and quality control information.</p>
 <p>It is important to check that the <code>write_diag</code> option in the GSI namelist is setup to <code>.true.</code>.</p>
-<p>By default the diag files are saved in binary format, and while GSI should be able to saved them as netcdfs, I have never made it work. So, this section will concentrate on how to decode the binary files and how to interpret the information.</p>
-<p>Here is a list of the files you get if you run GSI as observation operator, in this case we are assimilating AMSU-A observation from the NOAA-18 and METOP-A satellites, ABI observations from GOES-16 and conventional observations. To be able to use this output with the Kalman Filter methods we need the diag files for the ensemble mean and every member.</p>
+<p>By default the diag files are saved in binary format, and while GSI should be able to saved them as netCDFs, I have never made it work. So, this section will concentrate on how to decode the binary files and how to interpret the information.</p>
+<p>Here is a list of the files you get if you run GSI as observation operator, in this case we are assimilating AMSU-A observation from the NOAA-18 and METOP-A satellites, ABI observations from GOES-16 and conventional observations. To be able to use this output with the Kalman Filter methods we need the diag files for the ensemble mean and each member.</p>
 <div class="sourceCode" id="cb1"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">diag_abi_g16_ges.ensmean</span></span>
 <span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a><span class="ex">diag_abi_g16_ges.mem001</span></span>
 <span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a><span class="ex">diag_abi_g16_ges.mem002</span></span>
@@ -269,8 +269,8 @@ <h1 class="title">Undestanding diag(nostic) files</h1>
 <span id="cb1-42"><a href="#cb1-42" aria-hidden="true" tabindex="-1"></a><span class="ex">diag_conv_ges.mem008</span></span>
 <span id="cb1-43"><a href="#cb1-43" aria-hidden="true" tabindex="-1"></a><span class="ex">diag_conv_ges.mem009</span></span>
 <span id="cb1-44"><a href="#cb1-44" aria-hidden="true" tabindex="-1"></a><span class="ex">diag_conv_ges.mem010</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
-<p>GSI includes some fortran routines you can use to decode the binary files. In may case I decided to modify those routines to get the information as a tidy table (1 observation per row, variables in columns) and to include more details present in the diagfiles.</p>
-<p>The code is published <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3/tree/main/util/read_diag">in this repository</a>, that includes a version of GSI with some modidications:</p>
+<p>GSI includes some fortran routines you can use to decode the binary files. In my case I decided to modify those routines to get the information as a tidy table (1 observation per row, variables in columns) and to include more details present in the diagfiles.</p>
+<p>The code is published <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3/tree/main/util/read_diag">in this repository</a>, that includes a version of GSI with my modifications:</p>
 <div class="sourceCode" id="cb2"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ex">read_diag/</span></span>
 <span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a><span class="ex">├──</span> convinfo</span>
 <span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a><span class="ex">├──</span> namelist.conv</span>
@@ -289,20 +289,20 @@ <h1 class="title">Undestanding diag(nostic) files</h1>
 <span id="cb2-16"><a href="#cb2-16" aria-hidden="true" tabindex="-1"></a>    <span class="ex">├──</span> read_diag_rad.f90</span>
 <span id="cb2-17"><a href="#cb2-17" aria-hidden="true" tabindex="-1"></a>    <span class="ex">└──</span> read_diag_rad.f90_original</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 <p>There are 2 fortran routines, <code>read_diag_conv.f90</code> for conventional diag files and <code>read_diag_rad.f90</code> for radiances. To compile the routines it is necessary to link them with the libraries that GSI uses. An example of how to compile the code can be found in <code>compile_gcc</code> and <code>compile_ifort</code>.</p>
-<p>The resulting executables are <code>read_diag_conv.x</code> and <code>read_diag_rad.x</code>. Each one is asociated to a namelist that you need to modify each time in order to run the code and decode an especific diagfile. See for example the content of <code>namelist.conv</code>:</p>
+<p>The resulting executables are <code>read_diag_conv.x</code> and <code>read_diag_rad.x</code>. Each one is associated to a namelist that you need to modify each time in order to run the code and decode an specific diagfile. See for example the content of <code>namelist.conv</code>:</p>
 <div class="sourceCode" id="cb3"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="kw">&amp;</span><span class="ex">iosetup</span></span>
 <span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a>  <span class="va">infilename</span><span class="op">=</span><span class="st">'/home/paola.corrales/datosmunin3/EXP/E6_long/ANA/20181112220000/diagfiles/diag_conv_ges.ensmean'</span>,</span>
 <span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a>  <span class="va">outfilename</span><span class="op">=</span><span class="st">'/home/paola.corrales/datosmunin3/EXP/E6_long/ANA/20181112220000/diagfiles/asim_conv_20181112220000.ensmean'</span>,</span>
 <span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a> <span class="ex">/</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
-<p>The namelist is very simple, it only need the path to the diag file and the path to the output: a plain text file. But if you need to do this for every diag file, it is very time consuming. For that reason I wrote in bash some loops to go through all the diagfiles and decode them automatically. There are 4 bash files, to decode conventional diagfiles (ensemble mean or the members of the ensemble) and 2 for the radiance diagfiles. I’ve also kept the original fortran routines just in case.</p>
+<p>The namelist is very simple, it only need the path to the diag file and the path to the output: a plain text file. But if you need to do this for every diag file, it is very time consuming. For that reason I wrote in bash some loops to go through all the diagfiles and decode them automatically. There are 4 bash files, 2 to decode conventional diagfiles (ensemble mean or the members of the ensemble) and 2 for the radiance diagfiles. I’ve also kept the original fortran routines just in case.</p>
 <section id="conventional-obs" class="level3">
 <h3 class="anchored" data-anchor-id="conventional-obs">Conventional obs</h3>
 <p>This is the information you get when you decode a conventional diagfile using the <code>read_diag_conv.x</code>:</p>
 <ul>
 <li>variable</li>
 <li>stationID</li>
-<li>type (acording to the prepbufr)</li>
-<li>dhr (difference between the obserbation time and the analysis time)</li>
+<li>type (according to the prepbufr)</li>
+<li>dhr (difference between the observation time and the analysis time)</li>
 <li>latitude</li>
 <li>longitude</li>
 <li>pressure</li>
@@ -310,8 +310,8 @@ <h3 class="anchored" data-anchor-id="conventional-obs">Conventional obs</h3>
 <li>usage flag preprepbufr</li>
 <li>observation</li>
 <li>observation minus guess</li>
-<li>observation (only of uv)</li>
-<li>observation minus guess (only of uv)</li>
+<li>observation (only if uv)</li>
+<li>observation minus guess (only if uv)</li>
 <li>observation error</li>
 </ul>
 <p>Each row is an observation, except for wind that has u and v components in the same row.</p>
@@ -327,7 +327,7 @@ <h3 class="anchored" data-anchor-id="conventional-obs">Conventional obs</h3>
 <span id="cb4-10"><a href="#cb4-10" aria-hidden="true" tabindex="-1"></a>  <span class="ex">q</span> @ SCJO     : 187     <span class="at">-0.50</span>  <span class="at">-40.60</span>  286.95   0.999E+03    1    0   0.107E-01   0.110E-02   0.112E-01   0.100E+11   0.225E-02</span>
 <span id="cb4-11"><a href="#cb4-11" aria-hidden="true" tabindex="-1"></a> <span class="ex">uv</span> @ IR270    : 245      0.00  <span class="at">-39.36</span>  285.57   0.270E+03   <span class="at">-1</span>  100   0.434E+02  <span class="at">-0.363E+01</span>  <span class="at">-0.193E+02</span>   0.614E+00   0.684E+01</span>
 <span id="cb4-12"><a href="#cb4-12" aria-hidden="true" tabindex="-1"></a> <span class="ex">uv</span> @ IR270    : 245      0.00  <span class="at">-39.31</span>  286.11   0.269E+03   <span class="at">-1</span>  100   0.434E+02  <span class="at">-0.225E+01</span>  <span class="at">-0.193E+02</span>  <span class="at">-0.108E+01</span>   0.685E+01</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
-<p>The diag file includes more details. It may be useful to read the subroutine that write the diag files. The subroutine is called <code>contents_binary_diag_</code> and is present in each <code>setup*.f90</code> file. But here is a tip, it is much easier to read the <code>contents_netcdf_diag_</code> subroutine because it mention the name of each variable to create the metadata of the netcdf file.</p>
+<p>The diag file includes more details. It may be useful to read the subroutine that write the diag files. The subroutine is called <code>contents_binary_diag_</code> and is present in each <code>setup*.f90</code> file. But here is a tip, it is much easier to read the <code>contents_netcdf_diag_</code> subroutine because it mention the name of each variable to create the metadata of the netCDF file.</p>
 </section>
 <section id="radiance-obs" class="level3">
 <h3 class="anchored" data-anchor-id="radiance-obs">Radiance obs</h3>
diff --git a/content/gsi/05-tutorial.html b/content/gsi/05-tutorial.html
index c68e4d7..619862c 100644
--- a/content/gsi/05-tutorial.html
+++ b/content/gsi/05-tutorial.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - GSI tutorial</title>
+<title>Data Assimilation docs - GSI tutorial</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -113,7 +113,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="../../index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -195,6 +195,7 @@ <h2 id="toc-title">On this page</h2>
   <ul>
   <li><a href="#moving-parts" id="toc-moving-parts" class="nav-link active" data-scroll-target="#moving-parts">Moving parts</a>
   <ul class="collapse">
+  <li><a href="#gsi-code" id="toc-gsi-code" class="nav-link" data-scroll-target="#gsi-code">GSI code</a></li>
   <li><a href="#observations" id="toc-observations" class="nav-link" data-scroll-target="#observations">Observations</a></li>
   <li><a href="#background" id="toc-background" class="nav-link" data-scroll-target="#background">Background</a></li>
   </ul></li>
@@ -235,12 +236,15 @@ <h1 class="title">GSI tutorial</h1>
 </header>
 
 
-<p>This tutorial is intended to showcase some of the capabilities of the GSI system. For a more complete set of examples, please visit the official website for GSI: <a href="https://dtcenter.org/community-code/gridpoint-statistical-interpolation-gsi">variational methods</a> and [Kalman Filter](<a href="https://dtcenter.org/community-code/ensemble-kalman-filter-system-enkf" class="uri">https://dtcenter.org/community-code/ensemble-kalman-filter-system-enkf</a>) methods.</p>
+<p>This tutorial is intended to showcase some of the capabilities of the GSI system. For a more complete set of examples, please visit the official website for GSI: <a href="https://dtcenter.org/community-code/gridpoint-statistical-interpolation-gsi">variational methods</a> and <a href="https://dtcenter.org/community-code/ensemble-kalman-filter-system-enkf">Kalman Filter</a> methods.</p>
 <p>The tutorial uses the serial Ensemble Square Root Filter (EnSRF) algorithm but could also be used to run the Local Ensemble Kalman Filter (LETKF) algorithm if the GSI system code is compiled using a intel compiler<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>. It also uses a version of the code that have the capability of assimilating GOES-16 observations.</p>
 <section id="moving-parts" class="level2">
 <h2 class="anchored" data-anchor-id="moving-parts">Moving parts</h2>
-<p>The first component to run the tutorial is the GSI system code that can be found in this repository: <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3">github.com/paocorrales/comGSIv3.7_EnKFv1.3</a>. Alternatively, the original code without modifications is available <a href="https://dtcenter.org/community-code/gridpoint-statistical-interpolation-gsi">here</a>. The repository includes an example script <code>compile_gsi_yakaira</code> to compile the code. In any case it is important to include the option <code>-DBUILD_WRF=ON</code> to use the ENKF algorithm with WRF.</p>
+<section id="gsi-code" class="level3">
+<h3 class="anchored" data-anchor-id="gsi-code">GSI code</h3>
+<p>The first component to run the tutorial is the GSI system code that can be found in this repository: <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3">github.com/paocorrales/comGSIv3.7_EnKFv1.3</a>. Alternatively, the original code without modifications is available <a href="https://dtcenter.org/community-code/gridpoint-statistical-interpolation-gsi">here</a>. The repository includes an example script <code>compile_gsi_yakaira</code> to compile the code. In any case it is important to include the option <code>-DBUILD_WRF=ON</code> to use the ENKF algorithm with WRF as model.</p>
 <p>Then, clone or download the repository with the scripts, namelists and specific config files from: <a href="https://github.com/paocorrales/tutorial_gsi" class="uri">https://github.com/paocorrales/tutorial_gsi</a>. This repository also includes a bash scripts to download the necessary data to run the tutorial. This data is also available as a <a href="https://zenodo.org/records/10439645">Zenodo record</a>.</p>
+</section>
 <section id="observations" class="level3">
 <h3 class="anchored" data-anchor-id="observations">Observations</h3>
 <p>The observations included in this tutorial are:</p>
@@ -248,7 +252,7 @@ <h3 class="anchored" data-anchor-id="observations">Observations</h3>
 <ul>
 <li>File: <code>cimap.20181122.t12z.01h.prepbufr.nqc</code></li>
 </ul>
-<p><strong>Radiance observations:</strong> radiances from polar and geostationary satellites. Observations from polar satellites comes from the Global Data Assimilation System (GDAS) Model: <a href="https://www.nco.ncep.noaa.gov/pmb/products/gfs" class="uri">https://www.nco.ncep.noaa.gov/pmb/products/gfs</a>. The GOES-16 observations (ABI sensor) are derived from the public netcdf files published by NOAA.</p>
+<p><strong>Radiance observations:</strong> radiances from polar and geostationary satellites. Observations from polar satellites comes from the Global Data Assimilation System (GDAS) Model: <a href="https://www.nco.ncep.noaa.gov/pmb/products/gfs" class="uri">https://www.nco.ncep.noaa.gov/pmb/products/gfs</a>. The GOES-16 observations (ABI sensor) are derived from the public netCDF files published by NOAA.</p>
 <p>Files:</p>
 <ul>
 <li><code>abig16.20181122.t12z.bufr_d</code></li>
@@ -273,7 +277,7 @@ <h3 class="anchored" data-anchor-id="background">Background</h3>
 </section>
 <section id="structure" class="level2">
 <h2 class="anchored" data-anchor-id="structure">Structure</h2>
-<p>By cloning the tutorial repo and downloading the associated data with the provied script you will end up with the following folder structure.</p>
+<p>By cloning the tutorial repo and downloading the associated data with the provided script (<a href="https://github.com/paocorrales/tutorial_gsi/blob/main/download_data.sh" title="download_data.sh">download_data.sh</a>) you will end up with the following folder structure.</p>
 <div class="sourceCode" id="cb1"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">tutorial_gsi/</span></span>
 <span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a><span class="ex">├──</span> download_data.sh</span>
 <span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a><span class="ex">├──</span> fix</span>
@@ -396,7 +400,7 @@ <h2 class="anchored" data-anchor-id="structure">Structure</h2>
 </section>
 <section id="fgat" class="level2">
 <h2 class="anchored" data-anchor-id="fgat">Running GSI</h2>
-<p>As we focus on running GSI with the Kalman Filter method, the first stem is to run GSI as Observation operator. So, the system will compare the observations with the background state and and save that information in diagnostic files.</p>
+<p>As we focus on running GSI with the Kalman Filter method, the first step is to run GSI as Observation operator. So, the system will compare the observations with the background state and and save that information in diagnostic files.</p>
 <p>The example used in this tutorial is relatively small, so while you may need a HPC system for real cases, this one can be run in a small server or even a computer with at least 10 processors.</p>
 <p>Here are the ~20 first lines of the script <code>run_gsi.sh</code>:</p>
 <div class="sourceCode" id="cb2"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="co">#PBS -N </span><span class="al">TEST</span><span class="co">-1-GSI </span></span>
@@ -420,7 +424,7 @@ <h2 class="anchored" data-anchor-id="fgat">Running GSI</h2>
 <span id="cb2-19"><a href="#cb2-19" aria-hidden="true" tabindex="-1"></a><span class="va">GSIPROC</span><span class="op">=</span>10</span>
 <span id="cb2-20"><a href="#cb2-20" aria-hidden="true" tabindex="-1"></a></span>
 <span id="cb2-21"><a href="#cb2-21" aria-hidden="true" tabindex="-1"></a><span class="ex">set-x</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
-<p>In principle, you only need to change <code>BASEDIR</code> and <code>GSIDIR</code> variables that are the path to the tutorial folder and the path to where GSI is compiled (the code expects to find a <code>build</code> folder with the executable files.</p>
+<p>In principle, you only need to change <code>BASEDIR</code> and <code>GSIDIR</code> variables that are the path to the tutorial folder and the path to where GSI is compiled (the code expects to find a <code>build</code> folder with the executable files inside <code>GSIDIR</code>).</p>
 <p>So, with that, you can run the script or send it to a queue.</p>
 <section id="issues-gsi" class="level3">
 <h3 class="anchored" data-anchor-id="issues-gsi">Possible issues</h3>
@@ -441,7 +445,7 @@ <h3 class="anchored" data-anchor-id="did-it-work">Did it work?</h3>
 <p>If you get a <code>exit 0</code> at the end, it probably means that everything went well. However, I recommend you check a few things to make sure everything went <em>really</em> well.</p>
 <ul>
 <li>Check that all the <code>diag*</code> files are there. You will get 1 file per member and ensemble mean for each type of observation. If you don’t see any of these files, check the <a href="@issues-gsi">Issues</a> section. If you are missing the files for 1 type of observation, that probably means that the bufr file with the observations was not read properly or that is missing in the folder. Check if the script is linking the correct file to the <code>GSI</code> folder.</li>
-<li>Check the statistics for each type of observations. You will find this information in the <code>fit_&lt;obs&gt;.&lt;date&gt;</code> files. Each one may have different information or structure depending on the type of observation, but make sure to check the number of observations read and keep by the system. This information is also included in the <code>stdout</code> file, you can sear <code>READ_*</code> to find the section in the file.</li>
+<li>Check the statistics for each type of observations. You will find this information in the <code>fit_&lt;obs&gt;.&lt;date&gt;</code> files. Each one may have different information or structure depending on the type of observation, but make sure to check the number of observations read and keep by the system. This information is also included in the <code>stdout</code> file, you can search for <code>READ_*</code> to find the section in the file.</li>
 </ul>
 <p>If you got an error number instead and, if you are lucky, the error code may be described in <code>gsimain.f90</code>.</p>
 </section>
@@ -487,14 +491,14 @@ <h3 class="anchored" data-anchor-id="did-it-work-1">Did it work?</h3>
 </section>
 <section id="running-gsi-using-the-fgat-method" class="level2">
 <h2 class="anchored" data-anchor-id="running-gsi-using-the-fgat-method">Running GSI using the FGAT method</h2>
-<p>The tutorial is configured to use the FGAT (First Guess at Appropriate Time) methods, this means that will GSI attempt to read multiple time level backgrounds a show in the following diagram.</p>
+<p>The tutorial is configured to use the FGAT (First Guess at Appropriate Time) methods, this means that will GSI attempt to read multiple time level backgrounds as show in the following diagram.</p>
 <div class="quarto-figure quarto-figure-center">
 <figure class="figure">
 <p><img src="img/fgat_diagram.png" class="img-fluid figure-img" alt="A diagram that shows the assimilation window of 1 h centered at 12 UTC. The observations are used every 10 minutes"></p>
 <figcaption>FGAT method</figcaption>
 </figure>
 </div>
-<p>There is no option in the namelist or configuration files to use the FGAT method. To “activate” this option GSI needs to find the appropiate files in appropriate folder. In this example we have 7 files in total for each member, 1 background file at the assimilation time plus 3 files every 10 minutes before and after the assimilation time.</p>
+<p>There is no option in the namelist or configuration files to use the FGAT method. To “activate” this option GSI needs to find the appropriate files in appropriate folder. In this example we have 7 files in total for each member, 1 background file at the assimilation time plus 3 files every 10 minutes before and after the assimilation time.</p>
 <p>So, GSI will expect to find files called <code>wrf_inou1</code> to <code>wrf_inou7</code>. The fonder structure looks like this:</p>
 <div class="sourceCode" id="cb5"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a><span class="ex">GUESS/</span></span>
 <span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a><span class="ex">└──</span> 20181122120000</span>
@@ -613,7 +617,7 @@ <h2 class="anchored" data-anchor-id="running-gsi-using-the-fgat-method">Running
 <span id="cb10-8"><a href="#cb10-8" aria-hidden="true" tabindex="-1"></a> <span class="ex">start_index</span> =            1           1           1           0</span>
 <span id="cb10-9"><a href="#cb10-9" aria-hidden="true" tabindex="-1"></a> <span class="ex">end_index</span> =          199         239           4           0</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 <p>You’ll know that GSI is using the FGAT method. The example here shows that GSI found the <code>wrf_inout1</code> file that is renaming to <code>sig01</code> and then, information related to the time and domain characteristics. This will be repeated for each background file. In this case the first file corresponds to th 11:30 UTC of November 2018 and after that there is 1 file every 10 minutes.</p>
-<p>This period between background files (10 minutes) is defined by the user when saving the background files. Again there is no configuration option to do this. GSI relies on finding the files in the especified folder.</p>
+<p>This period between background files (10 minutes) is defined by the user when saving the background files. Again there is no configuration option to do this. GSI relies on finding the files in the specified folder.</p>
 <hr>
 <div class="callout callout-style-default callout-important callout-titled">
 <div class="callout-header d-flex align-content-center">
diff --git a/content/observations/01-bufr.html b/content/observations/01-bufr.html
index b9eefbf..355cce4 100644
--- a/content/observations/01-bufr.html
+++ b/content/observations/01-bufr.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - Working with bufr files</title>
+<title>Data Assimilation docs - Working with bufr files</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -113,7 +113,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="../../index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -230,9 +230,9 @@ <h1 class="title">Working with bufr files</h1>
 <p>A message is a continuous binary stream that can be divided into 6 sections:</p>
 <table class="table">
 <colgroup>
-<col style="width: 15%">
-<col style="width: 31%">
-<col style="width: 53%">
+<col style="width: 21%">
+<col style="width: 28%">
+<col style="width: 49%">
 </colgroup>
 <thead>
 <tr class="header">
@@ -360,7 +360,7 @@ <h2 class="anchored" data-anchor-id="an-introduction-on-how-to-read-and-write-bu
 <p>And again, BUFR files will be different for different type of observations and you always need the associated mnemonics table.</p>
 <section id="decode-prepbufr-files" class="level3">
 <h3 class="anchored" data-anchor-id="decode-prepbufr-files">Decode prepBUFR files</h3>
-<p>This is not different that we’ve seen previously and the BUFR tools fonder in the GSI code has very good examples to use. But I like to have the data in tidy tables, so I’ve modified that code to decode a prepBUFR file into a table where each row is an observation. This is the routine:</p>
+<p>This is not different that we’ve seen previously and the <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3/tree/main/util/bufr_tools">BUFR tools folder</a> in the GSI repository has very good examples to use. But I like to have the data in tidy tables, so I’ve modified that code to decode a prepBUFR file into a table where each row is an observation. This is the routine:</p>
 <div class="sourceCode" id="cb7"><pre class="sourceCode fortran code-with-copy"><code class="sourceCode fortranfixed"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a><span class="kw">program</span> prepbufr_decode_all_df</span>
 <span id="cb7-2"><a href="#cb7-2" aria-hidden="true" tabindex="-1"></a><span class="co">!</span></span>
 <span id="cb7-3"><a href="#cb7-3" aria-hidden="true" tabindex="-1"></a><span class="co">! read all observations out from prepbufr. </span></span>
diff --git a/content/observations/02-conv-bufr.html b/content/observations/02-conv-bufr.html
index 29469e7..f7494f4 100644
--- a/content/observations/02-conv-bufr.html
+++ b/content/observations/02-conv-bufr.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - Conventional obs bufr</title>
+<title>Data Assimilation docs - Conventional obs bufr</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -133,7 +133,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="../../index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -242,7 +242,7 @@ <h1 class="title">Conventional obs bufr</h1>
 
 
 <p>This section covers how to add new surface observations to prepBUFR and how to divide a file into smaller subsets.</p>
-<p>One of the first challenges (besides to learning how to use GSI and deal with bufr files) was to incorporate surface observations from automatic stations to the assimilation. In Argentina there are very few official stations to cover the entire country but there are private automatic station network that could potentially help to improve weather forecasts thank to their higher frequency (10 minutes) and spacial resolution.</p>
+<p>One of the first challenges (besides learning how to use GSI and deal with bufr files) was to incorporate surface observations from automatic stations to the assimilation. In Argentina there are very few official stations to cover the entire country but there are private automatic station network that could potentially help to improve weather forecasts thank to their higher frequency (10 minutes) and spacial resolution.</p>
 <div class="quarto-figure quarto-figure-center">
 <figure class="figure">
 <p><img src="img/ema.png" class="img-fluid figure-img" width="500"></p>
@@ -252,8 +252,8 @@ <h1 class="title">Conventional obs bufr</h1>
 <p>This requires to incorporate these new observations <span class="citation" data-cites="garcia2019">(available at <a href="#ref-garcia2019" role="doc-biblioref">Garcia et al. 2019</a>)</span> to the prepBUFR (so, be able to write fortran code and understand the bufr format). The 2 programs included here are based on the INPE/CPTEC modules and programs that are part of their operational assimilation system. I was lucky to visit CPTEC in 2019 where I learned how to work with these tools.</p>
 <section id="add-observations-to-a-prepbufr-file" class="level2">
 <h2 class="anchored" data-anchor-id="add-observations-to-a-prepbufr-file">Add observations to a prepBUFR file</h2>
-<p>In the previous section I briefly explained how to read and write a bufr file. To <em>add</em> new observations to an existing file (o to a new file!) we use the same functions mentioned <a href="#an-introduction-on-how-to-read-and-write-bufr-files">here</a> and structure of the routine is also similar. But we also need to figure out how to read the new observations and how to create new reports.</p>
-<p>The code I’m sharing here assume that the new observations are in csv format and has the following look:</p>
+<p>In the <a href="obs/01-bufr.qmd">previous section</a> I briefly explained how to read and write a bufr file. To <em>add</em> new observations to an existing file (o to a new file!) we use the same functions mentioned <a href="#an-introduction-on-how-to-read-and-write-bufr-files">here</a> and structure of the routine is also similar. But we also need to figure out how to read the new observations into fortran and how to create new reports.</p>
+<p>The code I’m sharing here assume that the new observations are in csv format and has the following look (without the header):</p>
 <table class="table">
 <colgroup>
 <col style="width: 10%">
@@ -354,15 +354,15 @@ <h2 class="anchored" data-anchor-id="add-observations-to-a-prepbufr-file">Add ob
 </div>
 </div>
 <div class="callout-body-container callout-body">
-<p>If you want to convert the files available here into csv tables, <a href="https://gist.github.com/paocorrales/e68daf085cf16b5d2e48f11513392084">here is an R script to do that</a>.</p>
+<p>If you want to convert the files available <a href="https://data.eol.ucar.edu/dataset/553.008">here</a> into csv tables, <a href="https://gist.github.com/paocorrales/e68daf085cf16b5d2e48f11513392084">I wrote an R script to do that</a>.</p>
 </div>
 </div>
-<p>The program read the configuration file that define where is the namelist and the prepbufr table and call a function that start the process. The namelist will list the name of the prepbufr to modify and the csv files with the new observations. The most important subroutine is <code>adpsfc_rw_prepbufr()</code>:</p>
+<p>The program read the configuration file (<code>add_obs.conf</code>) that define where is the namelist and the prepbufr table and call a function that start the process. The namelist will list the name of the prepbufr file to modify and the csv files with the new observations. The most important subroutine is <code>adpsfc_rw_prepbufr()</code> that:</p>
 <ol type="1">
 <li>Reads the bufr file</li>
 <li>Reads the csv with new observations</li>
 <li>Decides if the observations fall into the time window</li>
-<li>Creates a new report type 187</li>
+<li>Creates a new report type 187 (check obs types <a href="https://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_2.htm">here</a>)</li>
 <li>Write the bufr file</li>
 </ol>
 <div class="quarto-figure quarto-figure-center">
@@ -385,9 +385,9 @@ <h2 class="anchored" data-anchor-id="filter-observations-in-a-prepbufr">Filter o
 </section>
 <section id="the-code" class="level2">
 <h2 class="anchored" data-anchor-id="the-code">The code</h2>
-<p>The source code is publicly available in <a href="https://github.com/paocorrales/prepbufr_tools">this repository</a>. Each source folder includes a <code>compile</code> file as example of how to compile the program. It needs the bufr and <a href="https://www.nco.ncep.noaa.gov/pmb/docs/libs/w3lib/ncep_w3lib.shtml">w3lib</a> to work with times.</p>
-<p>The <code>run</code> folder includes all the configuration files, namelists and bufr tables. The can be uses to run the programs using the example observations available in the <code>example_obs</code> folder.</p>
-<p>Finally, if you ever need to do this for many files, the <code>run_bash</code> folder has 2 bash scripts that modify the namelist and run the programs in a loop.</p>
+<p>The source code is publicly available in <a href="https://github.com/paocorrales/prepbufr_tools">this repository</a>. Each source folder includes a <code>compile</code> file as example of how to compile the program. It needs the bufr library to work with bufr files and <a href="https://www.nco.ncep.noaa.gov/pmb/docs/libs/w3lib/ncep_w3lib.shtml">w3lib</a> library to work with times.</p>
+<p>The <code>run</code> folder includes all the configuration files, namelists and bufr tables. They can be uses as it is to run the programs using the example observations available in the <code>example_obs</code> folder.</p>
+<p>Finally, if you ever need to do this many files, the <code>run_bash</code> folder has 2 bash scripts that modify the namelist and run the programs in a loop.</p>
 <div class="sourceCode" id="cb1"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">prepbufr_tools</span></span>
 <span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a><span class="ex">├──</span> example_obs</span>
 <span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a><span class="ex">│&nbsp;&nbsp;</span> ├── 2018111719.csv</span>
@@ -426,7 +426,7 @@ <h2 class="anchored" data-anchor-id="the-code">The code</h2>
 </div>
 </div>
 <div class="callout-body-container callout-body">
-<p>Once again, this routines are based on the INPE/CPTEC modules and programs that are part of their operational assimilation system.</p>
+<p>Once again, this routines are based on the INPE/CPTEC modules and programs that are part of their operational assimilation system. I wouldn’t have been able to work with bufr files without the help and guidance of Luiz Sapucci and his team</p>
 </div>
 </div>
 
diff --git a/content/observations/03-rad-bufr.html b/content/observations/03-rad-bufr.html
index f5a5a9c..fd35f68 100644
--- a/content/observations/03-rad-bufr.html
+++ b/content/observations/03-rad-bufr.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - Radiance obs bufr</title>
+<title>Data Assimilation docs - Radiance obs bufr</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -113,7 +113,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="../../index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -221,7 +221,7 @@ <h1 class="title">Radiance obs bufr</h1>
 </header>
 
 
-<p>If you’ve read the previous sections, you know that working with bufr files is not easy. It is possible by now that the bufr files for ABI observations (from GOES satellites) are available everywhere. But if you try to run assimilation experiments for “old” cases like me you will need to convert the observations in netCDF to the bufr format. So, this section explains how to do that.</p>
+<p>If you’ve read the previous sections, you know that working with bufr files is not easy. It is possible by now that the bufr files for ABI observations (from GOES satellites) are available everywhere. But if you try to run assimilation experiments for “old” cases like me you will need to convert the observations in netCDF to bufr format. So, this section explains how to do that.</p>
 <div class="callout callout-style-default callout-important callout-titled">
 <div class="callout-header d-flex align-content-center">
 <div class="callout-icon-container">
@@ -235,16 +235,16 @@ <h1 class="title">Radiance obs bufr</h1>
 <p>The GSI version I used (available <a href="https://github.com/paocorrales/comGSIv3.7_EnKFv1.3">here</a>) to assimilate ABI observations assumes that the abi bufrs use the table I mention in this section and has the structure that produce the routine. If you get the bufr files from somewhere else, it may not work, sorry.</p>
 </div>
 </div>
-<p>The routine I used is based on a a routine written by Jamie Bresch from NCAR/MMM. I made a few modifications to work with the current GSI version.</p>
-<p>It read the netCDF metadata from the files listed in <code>flist.txt</code> (usually 1 per channel) and the cloud mask. Then, it calculate geometric/geographic variables like longitude, latitude, the projection, the zenith angle of the sun on that specific time, etc.</p>
-<p>After that it will read each variable, calculate the brightness temperature from radiance and the standard deviation of the brightness temperature at each point. It will then write the bufr file using the <code>bufrtab_NC021046.txt</code> table.</p>
+<p>The routine I used is based on a a routine written by Jamie Bresch from NCAR/MMM. I made a few modifications to work with the current GSI version but it is essentially the same.</p>
+<p>It read the netCDF metadata from the files listed in <code>flist.txt</code> (usually 1 file per channel and the cloud mask). Then, it calculate geometric/geographic variables like longitude, latitude, the projection, the zenith angle of the sun on that specific time, etc.</p>
+<p>After that it will read from the files each variable, calculate the brightness temperature from radiance and the standard deviation of the brightness temperature at each point. It will then write the bufr file using the <code>bufrtab_NC021046.txt</code> table.</p>
 <p>Like the other bufr routines, it uses a namelist:</p>
 <div class="sourceCode" id="cb1"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="kw">&amp;</span><span class="ex">data_nml</span></span>
 <span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a>  <span class="ex">nc_list_file</span> = <span class="st">'./flist.txt'</span></span>
 <span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a>  <span class="ex">data_dir</span> = <span class="st">'.'</span>, ! path of the GRB nc files</span>
 <span id="cb1-4"><a href="#cb1-4" aria-hidden="true" tabindex="-1"></a>  <span class="ex">data_id</span> = <span class="st">'OR_ABI-L1b-RadF-M3'</span>      ! prefix of the downloaded GRB nc files</span>
 <span id="cb1-5"><a href="#cb1-5" aria-hidden="true" tabindex="-1"></a>  <span class="ex">sat_id</span> = <span class="st">'G16'</span></span>
-<span id="cb1-6"><a href="#cb1-6" aria-hidden="true" tabindex="-1"></a>  <span class="ex">bufr_tbl_file</span> = <span class="st">'../bufrtab_NC021046.txt'</span></span>
+<span id="cb1-6"><a href="#cb1-6" aria-hidden="true" tabindex="-1"></a>  <span class="ex">bufr_tbl_file</span> = <span class="st">'./bufrtab_NC021046.txt'</span></span>
 <span id="cb1-7"><a href="#cb1-7" aria-hidden="true" tabindex="-1"></a>  <span class="ex">n_subsample</span> = 4  ! stride for reducing the output volume</span>
 <span id="cb1-8"><a href="#cb1-8" aria-hidden="true" tabindex="-1"></a><span class="ex">/</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 <section id="bufr-structure" class="level3">
@@ -260,20 +260,20 @@ <h3 class="anchored" data-anchor-id="bufr-structure">Bufr structure</h3>
 <li><p>SOZA: solar zenith angle</p></li>
 <li><p>SOLAZI: solar azimuth</p></li>
 </ul>
-<p>And the type of message will be NC021046.</p>
+<p>And the type of message will be NC021046 (ABI observations in clear sky).</p>
 </section>
 <section id="variables-in-the-bufr-file" class="level3">
 <h3 class="anchored" data-anchor-id="variables-in-the-bufr-file">Variables in the bufr file</h3>
-<p>The mnemonics for the important variables in the bufr are: <strong>TMBRST</strong> (brightness temperature in Kelvin), <strong>SDTB</strong> (standard deviation for brightness temperature in Kelvin), <strong>NCLDMNT</strong> (% of no cloud).</p>
+<p>The mnemonics for the important variables in the bufr are: <strong>TMBRST</strong> (brightness temperature in Kelvin), <strong>SDTB</strong> (standard deviation for brightness temperature in Kelvin), <strong>NCLDMNT</strong> (% of no cloud). It will include:</p>
 <ul>
 <li><p><strong>Brightness Temperature (TB)</strong> for each infrared channel.</p></li>
-<li><p><strong>Standard Deviation for Brightness Temperature (SDTB)</strong> is a 2D field. The SDTB a each grid point is calculated from the TB field using a 3 by 3 region around the point. If the TB changes much in that region it may indicate that is a cloud border. GSI uses this variable for channel 10 to reject observations contaminated by clouds.</p></li>
+<li><p><strong>Standard Deviation for Brightness Temperature (SDTB)</strong> is a 2D field. The SDTB a each grid point is calculated inside the routine from the TB field using a 3 by 3 region around the point. If the TB changes much in that region, i.e.&nbsp;has a big SDTB, it may indicate that is a cloud border. GSI uses this variable for channel 10 to reject observations contaminated by clouds.</p></li>
 <li><p><strong>Cloud Mask</strong> defined as the percentage of no cloud, meaning 1 = no clouds.</p></li>
 </ul>
 </section>
 <section id="the-code" class="level2">
 <h2 class="anchored" data-anchor-id="the-code">The code</h2>
-<p>The source code is publicly available in <a href="https://github.com/paocorrales/goesbufr">this repository</a>. The root folder includes a <code>compile</code> file as example of how to compile the program. It needs the bufr library to work and you can use the want that get compiled along with GSI.</p>
+<p>The source code is publicly available in <a href="https://github.com/paocorrales/goesbufr">this repository</a>. The root folder includes a <code>compile</code> file as example of how to compile the program. It needs the bufr library to work and you can use the one that get compiled along with GSI.</p>
 <p>The <code>rundir</code> folder includes all the configuration files, namelists and bufr tables. Once you compile the routine, you can try running an example using the example observations available in the <code>example_obs</code> folder. The <code>flist.txt</code> and <code>namelist.goes_nc2bufr</code> files are ready to work.</p>
 <p>Finally, if you ever need to do this for many files <code>run_goesbufr.sh</code> script will help you. It modify the namelist and run the programs in a loop.</p>
 <div class="sourceCode" id="cb2"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ex">goesbufr/</span></span>
diff --git a/contribute.html b/contribute.html
index a26b596..b5456c6 100644
--- a/contribute.html
+++ b/contribute.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - How to contribute</title>
+<title>Data Assimilation docs - How to contribute</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -79,7 +79,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="./index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -188,22 +188,22 @@ <h1 class="title">How to contribute</h1>
 </header>
 
 
-<p>This outlines how to propose a change to DA-documentation.</p>
+<p>This outlines how to propose a change to this website.</p>
 <section id="fixing-typos" class="level2">
 <h2 class="anchored" data-anchor-id="fixing-typos">Fixing typos</h2>
-<p>You can fix typos, spelling mistakes, or grammatical errors in the documentation directly using the GitHub web interface, as long as the changes are made in the source file. This will automatically open a pull request</p>
+<p>You can fix typos, spelling mistakes, or grammatical errors in the documentation directly using the GitHub web interface, as long as the changes are made in the source file. This will automatically open a pull request in the repo.</p>
 </section>
 <section id="bigger-changes" class="level2">
 <h2 class="anchored" data-anchor-id="bigger-changes">Bigger changes</h2>
-<p>If you want to make a bigger change, it’s a good idea to first file an issue to start a conversation.</p>
+<p>If you want to make a bigger change, it’s a good idea to first open an issue to start a conversation.</p>
 </section>
 <section id="pull-request-process" class="level2">
 <h2 class="anchored" data-anchor-id="pull-request-process">Pull request process</h2>
-<p>To open a pull request you’ll need to fork the repository. This website is builded with quarto, make sure you have it installed if you want to build the website locally to test the chances you are proposing.</p>
+<p>To open a pull request you’ll need to fork the repository. This website is built with quarto, make sure you have it installed if you want to build the website locally to test the chances you are proposing.</p>
 </section>
 <section id="acknowledgements" class="level2">
 <h2 class="anchored" data-anchor-id="acknowledgements">Acknowledgements</h2>
-<p>If you contribute to this guide, I’d like to publicly acknowledge you work. Please indicate in you PR if you want to be add to the <a href="./contributors.html">Contributors page</a>.</p>
+<p>If you contribute to this guide, I’d like to publicly acknowledge your work. Please indicate in you PR if you want to be add to the <a href="./contributors.html">Contributors page</a>.</p>
 
 
 </section>
diff --git a/contributors.html b/contributors.html
index 678717b..4def952 100644
--- a/contributors.html
+++ b/contributors.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - Contributors</title>
+<title>Data Assimilation docs - Contributors</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -79,7 +79,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="./index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
diff --git a/index.html b/index.html
index 9d00870..047c3d0 100644
--- a/index.html
+++ b/index.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation</title>
+<title>Data Assimilation docs</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -79,7 +79,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="./index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
@@ -159,9 +159,12 @@
     <h2 id="toc-title">On this page</h2>
    
   <ul>
-  <li><a href="#a-note-about-using-this-material" id="toc-a-note-about-using-this-material" class="nav-link active" data-scroll-target="#a-note-about-using-this-material">A note about using this material</a></li>
+  <li><a href="#welcome" id="toc-welcome" class="nav-link active" data-scroll-target="#welcome">Welcome!</a>
+  <ul class="collapse">
+  <li><a href="#a-note-about-using-this-material" id="toc-a-note-about-using-this-material" class="nav-link" data-scroll-target="#a-note-about-using-this-material">A note about using this material</a></li>
   <li><a href="#citing-this-guide" id="toc-citing-this-guide" class="nav-link" data-scroll-target="#citing-this-guide">Citing this guide</a></li>
   <li><a href="#do-you-want-to-contribute" id="toc-do-you-want-to-contribute" class="nav-link" data-scroll-target="#do-you-want-to-contribute">Do you want to contribute?</a></li>
+  </ul></li>
   </ul>
 <div class="toc-actions"><ul><li><a href="https://github.com/paocorrales/DA-documentation/edit/main/index.qmd" class="toc-action"><i class="bi bi-github"></i>Edit this page</a></li><li><a href="https://github.com/paocorrales/DA-documentation/issues/new/choose" class="toc-action"><i class="bi empty"></i>Report an issue</a></li></ul></div></nav>
     </div>
@@ -171,23 +174,12 @@ <h2 id="toc-title">On this page</h2>
 
 
 
-<div class="callout callout-style-default callout-important callout-titled">
-<div class="callout-header d-flex align-content-center">
-<div class="callout-icon-container">
-<i class="callout-icon"></i>
-</div>
-<div class="callout-title-container flex-fill">
-This is a work in progress
-</div>
-</div>
-<div class="callout-body-container callout-body">
-<p>Comeback later to see more or, if you want to contribute, open an issue in the associated repo.</p>
-</div>
-</div>
-<p>This website compiles a series of tutorials, scripts and in general a comprehensive documentation around the <a href="https://dtcenter.org/community-code/gridpoint-statistical-interpolation-gsi">GSI system V3.7 - EnKF V1.3</a>. It focus on the use of GSI as a observation operator along with the LETKF version. It covers everything you need from how to deal with observations (in bufr format), how to configure the system to how read and interpret GSI outputs.</p>
+<section id="welcome" class="level1">
+<h1>Welcome!</h1>
+<p>This website compiles a series of examples, tutorials, scripts and in general a comprehensive documentation around the <a href="https://dtcenter.org/community-code/gridpoint-statistical-interpolation-gsi">GSI system V3.7 - EnKF V1.3</a>. It focus on the use of GSI as a observation operator along with the EnKF version. It covers everything you need to know from how to deal with observations (in bufr format), how to configure the system to assimilate conventional and radiance observtions to how to read and interpret GSI outputs.</p>
 <section id="a-note-about-using-this-material" class="level2">
 <h2 class="anchored" data-anchor-id="a-note-about-using-this-material">A note about using this material</h2>
-<p>While the text in this guide is released under a <a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>, specific scripts or programming routines may have different licences and authors. If you use the material in any way, make sure to check the Licence note associated to each section and cite it appropriately.</p>
+<p>While the text in this guide is released under a <a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>, specific scripts or programming routines may have different licences and authors. If you use the material in any way, make sure to check the note associated to each section and cite it appropriately.</p>
 </section>
 <section id="citing-this-guide" class="level2">
 <h2 class="anchored" data-anchor-id="citing-this-guide">Citing this guide</h2>
@@ -198,6 +190,7 @@ <h2 class="anchored" data-anchor-id="do-you-want-to-contribute">Do you want to c
 <p>Any contribution is welcome, please read <a href="./contribute.html">this guide</a> to learn how to do it.</p>
 
 
+</section>
 </section>
 
 </main> <!-- /main -->
diff --git a/license.html b/license.html
index 837a4fb..7385d98 100644
--- a/license.html
+++ b/license.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DA-documentation - Licence</title>
+<title>Data Assimilation docs - Licence</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -79,7 +79,7 @@
       <div class="navbar-container container-fluid">
       <div class="navbar-brand-container mx-auto">
     <a class="navbar-brand" href="./index.html">
-    <span class="navbar-title">DA-documentation</span>
+    <span class="navbar-title">Data Assimilation docs</span>
     </a>
   </div>
             <div id="quarto-search" class="" title="Search"></div>
diff --git a/search.json b/search.json
index 41bf5cd..bbdfb17 100644
--- a/search.json
+++ b/search.json
@@ -11,28 +11,28 @@
     "href": "content/gsi/03-radiances.html",
     "title": "Assimilating Radiance Observations",
     "section": "",
-    "text": "Assimilating radiance observations is more complicated than assimilating conventional observations as radiances are not state variables. We need a observation operator to transform the model variables to radiances. GSI uses the Community Radiative Transfer Model (CRTM, Liu et al. 2008) as an operator of the radiance observations that calculates the brightness temperature simulated by the model in order to compare it with the observations from satellite sensors."
+    "text": "Assimilating radiance observations is more complicated than assimilating conventional observations as radiances are not state variables. We need a observation operator to transform the model variables to brightness temperature. GSI uses the Community Radiative Transfer Model (CRTM, Liu et al. 2008) as an operator of the radiance observations that calculates the brightness temperature simulated by the model in order to compare it with the observations from satellite sensors."
   },
   {
     "objectID": "content/gsi/03-radiances.html#the-crtm-radiative-transfer-model",
     "href": "content/gsi/03-radiances.html#the-crtm-radiative-transfer-model",
     "title": "Assimilating Radiance Observations",
     "section": "The CRTM radiative transfer model",
-    "text": "The CRTM radiative transfer model\nThe CRTM is a fast radiative transfer model that was jointly developed by the NOAA Center for Satellite Applications and Research and the Joint Center for Satellite Data Assimilation (JCSDA). It is a model widely used by the remote sensing community as it is open source and publicly available. In addition, it is used for satellite instrument calibration (Weng et al. 2013; Iacovazzi et al. 2020; Crews et al. 2021), and in turn to generate retrievals from satellite observations (Boukabara et al. 2011; H. Hu et al. 2019; H. Hu and Han 2021). It is also used as an operator of observations as part of the assimilation of satellite radiances (Tong et al. 2020; Barton et al. 2021).\nThe CRTM is capable of simulating microwave, infrared and visible radiances, under clear and cloudy sky conditions, using atmospheric profiles of pressure, temperature, humidity and other species such as ozone. Recently Cutraro, Galligani, and Skabar (2021) evaluated their takeoff in the region with good results in simulating GOES-16 observations.\nCRTM is a sensor-oriented radiative transfer model, i.e. it contains pre-calculated parameterizations and coefficient tables specifically for operational sensors. It includes modules that calculate thermal radiation from gaseous absorption, absorption and scattering by aerosols and clouds, and emission and reflection of radiation by the Earth’s surface. The inputs of CRTM include atmospheric state variables, e.g., temperature, water vapor, pressure, and ozone concentration in user-defined layers, and surface state variables and parameters, including emissivity, surface temperature, and wind.\nCRTM is capable to simulate satellite observations from the state of the atmosphere. This is necessary during the assimilation process but is also used to verify the accuracy and errors of radiance observations.\nThe necessary calculations to simulate observations has a very high computational cost as it requires transposing a high dimensional matrix and the minimization of a cost function. This \\(K^{*}\\) matrix is constructed from the partial derivatives of the radiances with respect to geophysical parameters. CRTM performs these calculations very quickly so it can be used in operational contexts.\nTo obtain fast results, CRTM applies certain simplifications and approximations when solving the radiative transfer equation. First, it assumes that the Earth’s atmosphere consists of plane-parallel and homogeneous layers in thermodynamic equilibrium and where three-dimensional and polarization effects can be ignored.\nIn the context of clear skies, it is also assumed that there is no scattering and only the absorption of gases in the atmosphere is considered. In cloudy skies, the scattering generated by clouds is included. In the latter case, the radiative transfer equation cannot be solved analytically and numerical solutions are used."
+    "text": "The CRTM radiative transfer model\nThe CRTM is a fast radiative transfer model that was jointly developed by the NOAA Center for Satellite Applications and Research and the Joint Center for Satellite Data Assimilation (JCSDA). It is a model widely used by the remote sensing community as it is open source and publicly available. In addition, it is used for satellite instrument calibration (Weng et al. 2013; Iacovazzi et al. 2020; Crews et al. 2021), and to generate retrievals from satellite observations (Boukabara et al. 2011; H. Hu et al. 2019; H. Hu and Han 2021). It is also used as an operator of observations as part of the assimilation of satellite radiances (Tong et al. 2020; Barton et al. 2021).\nThe CRTM is capable of simulating microwave, infrared and visible radiances, under clear and cloudy sky conditions, using atmospheric profiles of pressure, temperature, humidity and other species such as ozone. Recently Cutraro, Galligani, and Skabar (2021) evaluated their use in Argentina with good results in simulating GOES-16 observations.\nCRTM is a sensor-oriented radiative transfer model, i.e. it contains pre-calculated parameterizations and coefficient tables specifically for operational sensors. It includes modules that calculate thermal radiation from gaseous absorption, absorption and scattering by aerosols and clouds, and emission and reflection of radiation by the Earth’s surface. The inputs of CRTM include atmospheric state variables, e.g., temperature, water vapor, pressure, and ozone concentration in user-defined layers, and surface state variables and parameters, including emissivity, surface temperature, and wind.\nCRTM is capable to simulate satellite observations from the state of the atmosphere. This is necessary during the assimilation process but is also used to verify the accuracy and errors of radiance observations.\nThe necessary calculations to simulate observations has a very high computational cost as it requires transposing a high dimensional matrix and the minimization of a cost function. This \\(K^{*}\\) matrix is constructed from the partial derivatives of the radiances with respect to geophysical parameters. CRTM performs these calculations very quickly so it can be used in operational contexts.\nTo obtain fast results, CRTM applies certain simplifications and approximations when solving the radiative transfer equation. First, it assumes that the Earth’s atmosphere consists of plane-parallel and homogeneous layers in thermodynamic equilibrium and where three-dimensional and polarization effects can be ignored.\nIn the context of clear skies, it is also assumed that there is no scattering and only the absorption of gases in the atmosphere is considered. In cloudy skies, the scattering generated by clouds is included. In the latter case, the radiative transfer equation cannot be solved analytically and numerical solutions are used."
   },
   {
     "objectID": "content/gsi/03-radiances.html#specific-configuration",
     "href": "content/gsi/03-radiances.html#specific-configuration",
     "title": "Assimilating Radiance Observations",
     "section": "Specific configuration",
-    "text": "Specific configuration\nThe assimilation of radiance observations is controlled with the satinfo file and the GSI namelist. Let’s check the global_satinfo.txt file we get as an example:\n!sensor/instr/sat      chan iuse  error  error_cld  ermax   var_b    var_pg  icld_det icloud iaerosol\n amsua_n15               1   1    3.000   20.000    4.500   10.000    0.000     -2      1     -1\n amsua_n15               2   1    2.200   18.000    4.500   10.000    0.000     -2      1     -1\n amsua_n15               3   1    2.000   12.000    4.500   10.000    0.000     -2      1     -1\n amsua_n15               4   1    0.600    3.000    2.500   10.000    0.000     -2      1     -1\n amsua_n15               5   1    0.300    0.500    2.000   10.000    0.000     -2      1     -1\n amsua_n15               6  -1    0.230    0.300    2.000   10.000    0.000     -2      1     -1\n amsua_n15               7   1    0.250    0.250    2.000   10.000    0.000     -2      1     -1\n amsua_n15               8   1    0.275    0.275    2.000   10.000    0.000     -2      1     -1\n amsua_n15               9   1    0.340    0.340    2.000   10.000    0.000     -2      1     -1\n amsua_n15              10   1    0.400    0.400    2.000   10.000    0.000     -2      1     -1\n amsua_n15              11  -1    0.600    0.600    2.500   10.000    0.000     -2      1     -1\n amsua_n15              12   1    1.000    1.000    3.500   10.000    0.000     -2      1     -1\n amsua_n15              13   1    1.500    1.500    4.500   10.000    0.000     -2      1     -1\n amsua_n15              14  -1    2.000    2.000    4.500   10.000    0.000     -2      1     -1\n amsua_n15              15   1    3.500   18.000    4.500   10.000    0.000     -2      1     -1\n hirs3_n17               1  -1    2.000    0.000    4.500   10.000    0.000     -1     -1     -1\nThe file includes a line for each sensor/satellite and each channel (chan). Usually you will change the iuse and error columns to configure the assimilation of each channel. The options for iuse are:\n\n-2 do not use\n-1 monitor if diagnostics produced\n0 monitor and use in QC only\n1 use data with complete quality control\n2 use data with no airmass bias correction\n3 use data with no angle dependent bias correction\n4 use data with no bias correction\n\nDefining the observation error is one of the difficult part of the assimilation process, so I usually keep the GFS values to be on the safe side.\nTo successfully assimilate radiances using the EnKF method it is critical to save in the diag files the vertical location of each radiance observation that is estimated as the model level at which its weight function1 computed by CRTM maximize. It is also important to save the predictors calculated during the bias correction step.\nHere is an incomplete list of parameters in the GSI and ENKF namelists.\nGSI namelist\n\n\n\n\n\n\n\n\nParameter\nDescription\nNeeded value\n\n\n\n\npassive_bc\noption to turn on bias correction for passive (monitored) channels\n.true.\n\n\nuse_edges\noption to exclude radiance data on scan edges\n.false.\n\n\nlwrite_predterms\noption to write out actual predictor terms instead of predicted bias to the radiance diagnostic files\n.true.\n\n\nlwrite_peakwt\noption to write out the approximate pressure of the peak of the weighting function for satellite data to the radiance diagnostic\n.true.\n\n\nemiss_bc\noption to turn on emissivity bias predictor\n.true.\n\n\n\nThis namelist will also includes a list with the type of observations and the name of the bufr file for each one (dfile).\nENKF namelist\n\nThis namelist will also includes a list with the type of observations and the name of each one inside GSI. For example amsua_n15 represent the observations of the AMSU-A sensor on board NOAA-15.\n\n\n\n\n\n\n\nParameter\nDescription\nNeeded value\n\n\n\n\nadp_anglebc\nturn off or on the variational radiance angle bias correction\n.true.\n\n\nangord\norder of polynomial for angle bias correction\n4\n\n\nuse_edges\nlogical to use data on scan edges (.true.=to use)\n.false.\n\n\nemiss_bc\nIf true, turn on emissivity bias correction\n.true.\n\n\nupd_pred\nbias update indicator for radiance bias correction; 1.0=bias correction coefficients evolve\n1"
+    "text": "Specific configuration\nThe assimilation of radiance observations is controlled with the satinfo file and the GSI namelist. Let’s check the global_satinfo.txt file we get as an example:\n!sensor/instr/sat      chan iuse  error  error_cld  ermax   var_b    var_pg  icld_det icloud iaerosol\n amsua_n15               1   1    3.000   20.000    4.500   10.000    0.000     -2      1     -1\n amsua_n15               2   1    2.200   18.000    4.500   10.000    0.000     -2      1     -1\n amsua_n15               3   1    2.000   12.000    4.500   10.000    0.000     -2      1     -1\n amsua_n15               4   1    0.600    3.000    2.500   10.000    0.000     -2      1     -1\n amsua_n15               5   1    0.300    0.500    2.000   10.000    0.000     -2      1     -1\n amsua_n15               6  -1    0.230    0.300    2.000   10.000    0.000     -2      1     -1\n amsua_n15               7   1    0.250    0.250    2.000   10.000    0.000     -2      1     -1\n amsua_n15               8   1    0.275    0.275    2.000   10.000    0.000     -2      1     -1\n amsua_n15               9   1    0.340    0.340    2.000   10.000    0.000     -2      1     -1\n amsua_n15              10   1    0.400    0.400    2.000   10.000    0.000     -2      1     -1\n amsua_n15              11  -1    0.600    0.600    2.500   10.000    0.000     -2      1     -1\n amsua_n15              12   1    1.000    1.000    3.500   10.000    0.000     -2      1     -1\n amsua_n15              13   1    1.500    1.500    4.500   10.000    0.000     -2      1     -1\n amsua_n15              14  -1    2.000    2.000    4.500   10.000    0.000     -2      1     -1\n amsua_n15              15   1    3.500   18.000    4.500   10.000    0.000     -2      1     -1\n hirs3_n17               1  -1    2.000    0.000    4.500   10.000    0.000     -1     -1     -1\nThe file includes a line for each sensor/satellite and each channel (chan). Usually you will change the iuse and error columns to configure the assimilation of each channel. The options for iuse are:\n\n-2 do not use\n-1 monitor if diagnostics produced\n0 monitor and use in QC only\n1 use data with complete quality control\n2 use data with no airmass bias correction\n3 use data with no angle dependent bias correction\n4 use data with no bias correction\n\nDefining the observation error is one of the difficult part of the assimilation process, so I usually keep the GFS values to be on the safe side.\nTo successfully assimilate radiances using the EnKF method it is critical to save in the diag files the vertical location of each radiance observation that is estimated as the model level at which its weight function1 computed by CRTM maximize. It is also important to save the predictors calculated during the bias correction step.\nHere is an incomplete list of parameters in the GSI and ENKF namelists.\nGSI namelist\n\n\n\n\n\n\n\n\nParameter\nDescription\nNeeded value\n\n\n\n\npassive_bc\noption to turn on bias correction for passive (monitored) channels\n.true.\n\n\nuse_edges\noption to exclude radiance data on scan edges\n.false.\n\n\nlwrite_predterms\noption to write out actual predictor terms instead of predicted bias to the radiance diagnostic files\n.true.\n\n\nlwrite_peakwt\noption to write out the approximate pressure of the peak of the weighting function for satellite data to the radiance diagnostic\n.true.\n\n\nemiss_bc\noption to turn on emissivity bias predictor\n.true.\n\n\n\nThis namelist will also includes a list with the type of observations and the name of the bufr file for each one (dfile).\nENKF namelist\n\n\n\n\n\n\n\n\nParameter\nDescription\nNeeded value\n\n\n\n\nadp_anglebc\nturn off or on the variational radiance angle bias correction\n.true.\n\n\nangord\norder of polynomial for angle bias correction\n4\n\n\nuse_edges\nlogical to use data on scan edges (.true.=to use)\n.false.\n\n\nemiss_bc\nIf true, turn on emissivity bias correction\n.true.\n\n\nupd_pred\nbias update indicator for radiance bias correction; 1.0=bias correction coefficients evolve\n1\n\n\n\nThis namelist will also includes a list with the type of observations and the name of each one inside GSI. For example amsua_n15 represent the observations of the AMSU-A sensor on board NOAA-15."
   },
   {
     "objectID": "content/gsi/03-radiances.html#observation-errors-and-quality-control",
     "href": "content/gsi/03-radiances.html#observation-errors-and-quality-control",
     "title": "Assimilating Radiance Observations",
     "section": "Observation errors and quality control",
-    "text": "Observation errors and quality control\nThe preprocessing and quality control of the data is an essential step in the assimilation of radiances and depends on each sensor and channel. This process includes spatial thinning, bias correction, and in clear-sky applications, the detection of cloudy sky observations.\n\nThinning\nDuring the thinning process the observations to be assimilated are chosen based on their distance to the model grid points, the quality of the observation (based on available data quality information) and the number of available channels (for the same pixel and sensor). The thinning algorithm determines the quality of each observation based on the available information about the channels and their known errors, the type of surface below each pixel (preferring observations over the sea to those over land or snow) and predictors that give information about the quality of the observations (M. Hu et al. 2018). By applying the thinning we avoid incorporating information from smaller scale processes than the model can not represent and to reduce the error correlation of the observations from the same sensor.\nThe thinning resolution is configured in the GSI namelist:\nIn this case we have 3 possible mesh size in kilometers: dmesh(1)=120.0, dmesh(2)=60.0, dmesh(3)=10.0. We define which resolution to use for each sensor in the dthin column. Here amsua_n15 will use a thinning of 60 km and abi_g16 a thinning of 10 km.\n &OBS_INPUT\n   dmesh(1)=120.0, dmesh(2)=60.0, dmesh(3)=10.0, time_window_max=0.5,ext_sonde=.true.,\n /\nOBS_INPUT::\n!  dfile          dtype       dplat     dsis                 dval    dthin dsfcalc\n   amsuabufr      amsua       n15       amsua_n15           10.0     2     0\n   amsuabufr      amsua       n18       amsua_n18           10.0     2     0\n   amsuabufr      amsua       n19       amsua_n19           10.0     2     0\n   amsuabufr      amsua       metop-a   amsua_metop-a       10.0     2     0\n   amsuabufr      amsua       metop-b   amsua_metop-b       10.0     2     0\n   airsbufr       amsua       aqua      amsua_aqua           5.0     2     0\n   abibufr        abi         g16       abi_g16              1.0     3     0\nIf the value of dthin is:\n\nan integer less than or equal to zero, no thinning is needed\nan integer larger than zero, this kind of radiance data will be thinned using the mesh size defined as dmesh (dthin).\n\n\n\nBias correction\nAfter the thinning, a bias correction is applied. The bias correction methodology implemented in GSI depends on thermodynamic characteristics of the air and on the scan angle (Zhu et al. 2014). It is computed as a linear polynomial of N predictors \\(p_i(x)\\), with associated coefficients \\(beta_i\\). Therefore, the bias-corrected brightness temperature (\\(BT_{cb}\\)) can be obtained as:\n\\[\\mathrm{\\mathit{BT_{cb}} =\\mathit{ BT} + \\sum_{i = 0}^{N} \\beta_i p_i (x)}\\]\nThe polynomial has a constant bias correction term (\\(p_0 = 1\\)) while the remaining terms and their predictors are the cloud liquid water (CLW) content, the temperature laps rate, the square of the temperature laps rate, and the sensitivity to the surface emissivity to account for the difference between land and sea. The scan angle-dependent bias is modeled as a polynomial of 4\\(^\\circ\\) order (Zhu et al. 2014).\nIn the GSI system, the coefficients \\(\\beta_i\\) are trained using a variational estimation method that generates the \\(\\beta_i\\) that provides the best fit between the simulation and the observations. The EnKF step also calculate the coefficients for the assimilation.\nIt is important to evaluate the training of the coefficients and the performance of the bias correction. One way to train the coefficients according to Zhu et al. (2014) is to run the assimilation cycles for a long period of time, updating the coefficients at each cycle. While is possible to start the training with coefficients equal to zero, using the coefficients the GFS generates can help to speed up the process.\nTo check if the coefficients are correctly trained we can analysed the evolution of the different coefficients for each sensor and channel with time. As an example, here we show the coefficients for AMSU-A on board NOAA-15. Following Zhu et al. (2014), we expected the coefficients to reach a stable range of values after a certain period of time, this is evident for channel 4, 5, 6 and 8 but we see a continuous variation in channels 7 and 9.\n\n\n\nBias correction coefficients as function of time (days) for the training and experiment period. Channels 4 to 9 of AMSU-A on NOAA-15.\n\n\nUsing the resulting coefficients from the training period it is also important to check the impact of the bias correction. An easy way to see this is to calculate the mean difference between the observations and the first-guess (OmB) before and after the correction of the bias for each sensor. In the next figure there is an evident improvement as the mean OmB after the BC is now centered around zero and its standard deviation is smaller. This indicate that the BC correction worked as expected.\n\n\n\nMean difference between observations and first-guess after and before the correction of the bias calculate over a 3 days period for each sensor.\n\n\nThe training of the coefficients requires a lot of computational resources and can be challenging for observations from polar satellites used in regional applications. The reason for this is that the observations are only available 1 or 2 times a day, making the training a slow process. It is important to check that GSI is not penalizing the coefficients when there are no observations available.\nThe coefficients are saved in the satbias file, a plain text file that looks like this:\n    1 amsua_n15                1   0.423099E+00   0.481606E+06   999\n        2.680195    0.000000    0.001042    0.004029    0.228152    0.000000    0.000000   -0.009346    3.972107    2.986645\n       -4.770297   -1.960179\n    2 amsua_n15                2   0.235695E+00   0.519067E+06   999\n        1.704236    0.000000    0.010259   14.889464   -3.720292    0.000000    0.000000   -0.011583    3.896762    9.125687\n       -4.712555   -1.727947\n    3 amsua_n15                3   0.150663E+01   0.593685E+06   999\n        1.771621    0.000000    0.009938    0.507936   -0.328143    0.000000    0.000000   -0.013321   -2.458213   -0.946619\n       -1.233838    0.234034\n    4 amsua_n15                4   0.342465E+01   0.104715E+07   999\n       -0.123787    0.000000    0.013865    0.050019   -0.037143    0.000000    0.000000    0.007463   -0.460992   -0.542148\n       -0.876047   -0.110968\n    5 amsua_n15                5   0.445149E+01   0.112750E+07   999\n        0.332174    0.000000    0.007298    0.010457   -0.071543    0.000000    0.000000   -0.009200    0.827698   -0.965067\n       -1.350357    0.100073\nSo, for each sensor and satellite and each channel there are 12 coefficients that are updated in each assimilation cycle. I recommend to save these files to analyses the BC process. Radiance bias correction terms are as follows:\n\nglobal offset\nzenith angle predictor, is not used and set to zero now\ncloud liquid water predictor for clear-sky microwave radiance assimilation\nsquare of temperature laps rate predictor\ntemperature laps rate predictor\ncosinusoidal predictor for SSMI/S ascending/descending bias\nsinusoidal predictor for SSMI/S\nemissivity sensitivity predictor for land/sea differences\nfourth order polynomial of angle bias correction\nthird order polynomial of angle bias correction\nsecond order polynomial of angle bias correction\nfirst order polynomial of angle bias correction\n\nOn the other hand the predictors are saved in the diag files (see the Undestanding diag files section).\n\n\nCloud detection\nThe cloud pixel detection methodology depends on the wavelength of the observations. For microwave radiances, potentially cloud-contaminated observations are detected using scattering and Liquid Water Path (LWP) indices calculated from differences between different channels of each sensor (Weston et al. 2019; Zhu et al. 2016). For infrared channels, cloud contaminated observations are detected using the transmittance profile calculated by the CRTM model. In addition, GSI checks the difference between the observations and the simulated brightness temperature to detect cloudy pixels. A particular case is the ABI observations since the cloud mask (level 2 product) available at the same resolution as the observations is used. This cloud mask is generated by combining information from 8 channels of the ABI sensor from the spatial and temporal point of view.\n\n\nOther quality controls\nThe GSI quality control filters out those observations from channels close to the visible range over water surfaces with a zenith angle greater than 60\\(^{\\circ}\\) to reject those observations that could be contaminated by reflection. For infrared and microwave observations it also performs an emissivity check to detect observations contaminated by surface effects. Finally, a gross check is applied, i.e. the difference between the observation and the observation simulated by the model is compared with a predefined threshold depending on the observation error to reject erroneous observations."
+    "text": "Observation errors and quality control\nThe preprocessing and quality control of the data is an essential step in the assimilation of radiances and depends on each sensor and channel. This process includes spatial thinning, bias correction, and in clear-sky applications, the detection of cloudy sky observations.\n\nThinning\nDuring the thinning process the observations to be assimilated are chosen based on their distance to the model grid points, the quality of the observation (based on available data quality information) and the number of available channels (for the same pixel and sensor). The thinning algorithm determines the quality of each observation based on the available information about the channels and their known errors, the type of surface below each pixel (preferring observations over the sea to those over land or snow) and predictors that give information about the quality of the observations (M. Hu et al. 2018). By applying the thinning we avoid incorporating information from smaller scale processes than the model can not represent and to reduce the error correlation of the observations from the same sensor.\nThe thinning resolution is configured in the GSI namelist:\nIn this case we have 3 possible mesh size in kilometers: dmesh(1)=120.0, dmesh(2)=60.0, dmesh(3)=10.0. We define which resolution to use for each sensor in the dthin column. Here amsua_n15 will use a thinning of 60 km and abi_g16 a thinning of 10 km.\n &OBS_INPUT\n   dmesh(1)=120.0, dmesh(2)=60.0, dmesh(3)=10.0, time_window_max=0.5,ext_sonde=.true.,\n /\nOBS_INPUT::\n!  dfile          dtype       dplat     dsis                 dval    dthin dsfcalc\n   amsuabufr      amsua       n15       amsua_n15           10.0     2     0\n   amsuabufr      amsua       n18       amsua_n18           10.0     2     0\n   amsuabufr      amsua       n19       amsua_n19           10.0     2     0\n   amsuabufr      amsua       metop-a   amsua_metop-a       10.0     2     0\n   amsuabufr      amsua       metop-b   amsua_metop-b       10.0     2     0\n   airsbufr       amsua       aqua      amsua_aqua           5.0     2     0\n   abibufr        abi         g16       abi_g16              1.0     3     0\nIf the value of dthin is:\n\nan integer less than or equal to zero, no thinning is needed\nan integer larger than zero, this kind of radiance data will be thinned using the mesh size defined as dmesh (dthin).\n\n\n\nBias correction\nAfter the thinning, a bias correction is applied. The bias correction methodology implemented in GSI depends on thermodynamic characteristics of the air and on the scan angle (Zhu et al. 2014). It is computed as a linear polynomial of N predictors \\(p_i(x)\\), with associated coefficients \\(beta_i\\). Therefore, the bias-corrected brightness temperature (\\(BT_{cb}\\)) can be obtained as:\n\\[\\mathrm{\\mathit{BT_{cb}} =\\mathit{ BT} + \\sum_{i = 0}^{N} \\beta_i p_i (x)}\\]\nThe polynomial has a constant bias correction term (\\(p_0 = 1\\)) while the remaining terms and their predictors are the cloud liquid water (CLW) content, the temperature laps rate, the square of the temperature laps rate, and the sensitivity to the surface emissivity to account for the difference between land and sea. The scan angle-dependent bias is modeled as a polynomial of 4\\(^\\circ\\) order (Zhu et al. 2014).\nIn the GSI system, the coefficients \\(\\beta_i\\) are trained using a variational estimation method that generates the \\(\\beta_i\\) that provides the best fit between the simulation and the observations. The EnKF step also calculate the coefficients for the assimilation.\nIt is important to evaluate the training of the coefficients and the performance of the bias correction. One way to train the coefficients according to Zhu et al. (2014) is to run the assimilation cycles for a long period of time, updating the coefficients at each cycle. While is possible to start the training with coefficients equal to zero, using the coefficients the GFS generates can help to speed up the process.\nTo check if the coefficients are correctly trained we can analysed the evolution of the different coefficients for each sensor and channel with time. As an example, here we show the coefficients for AMSU-A on board NOAA-15. Following Zhu et al. (2014), we expected the coefficients to reach a stable range of values after a certain period of time, this is evident for channel 4, 5, 6 and 8 but we see a continuous variation in channels 7 and 9.\n\n\n\nBias correction coefficients as function of time (days) for the training and experiment period. Channels 4 to 9 of AMSU-A on NOAA-15.\n\n\nUsing the resulting coefficients from the training period it is also important to check the impact of the bias correction. An easy way to see this is to calculate the mean difference between the observations and the first-guess (OmB) before and after the correction of the bias for each sensor. In the next figure there is an evident improvement as the mean OmB after the BC is now centered around zero and its standard deviation is smaller. This indicate that the BC correction worked as expected.\n\n\n\nMean difference between observations and first-guess after and before the correction of the bias calculate over a 3 days period for each sensor.\n\n\nThe training of the coefficients requires a lot of computational resources and can be challenging for observations from polar satellites used in regional applications. The reason for this is that the observations are only available 1 or 2 times a day, making the training a slow process. It is important to check that GSI is not penalizing the coefficients when there are no observations available.\nThe coefficients are saved in the satbias file, a plain text file that looks like this:\n    1 amsua_n15                1   0.423099E+00   0.481606E+06   999\n        2.680195    0.000000    0.001042    0.004029    0.228152    0.000000    0.000000   -0.009346    3.972107    2.986645\n       -4.770297   -1.960179\n    2 amsua_n15                2   0.235695E+00   0.519067E+06   999\n        1.704236    0.000000    0.010259   14.889464   -3.720292    0.000000    0.000000   -0.011583    3.896762    9.125687\n       -4.712555   -1.727947\n    3 amsua_n15                3   0.150663E+01   0.593685E+06   999\n        1.771621    0.000000    0.009938    0.507936   -0.328143    0.000000    0.000000   -0.013321   -2.458213   -0.946619\n       -1.233838    0.234034\n    4 amsua_n15                4   0.342465E+01   0.104715E+07   999\n       -0.123787    0.000000    0.013865    0.050019   -0.037143    0.000000    0.000000    0.007463   -0.460992   -0.542148\n       -0.876047   -0.110968\n    5 amsua_n15                5   0.445149E+01   0.112750E+07   999\n        0.332174    0.000000    0.007298    0.010457   -0.071543    0.000000    0.000000   -0.009200    0.827698   -0.965067\n       -1.350357    0.100073\nSo, for each sensor and satellite and each channel there are 12 coefficients that are updated in each assimilation cycle. I recommend to save these files to analyses the BC process. Radiance bias correction terms are as follows:\n\nglobal offset\nzenith angle predictor, is not used and set to zero now\ncloud liquid water predictor for clear-sky microwave radiance assimilation\nsquare of temperature laps rate predictor\ntemperature laps rate predictor\ncosinusoidal predictor for SSMI/S ascending/descending bias\nsinusoidal predictor for SSMI/S\nemissivity sensitivity predictor for land/sea differences\nfourth order polynomial of angle bias correction\nthird order polynomial of angle bias correction\nsecond order polynomial of angle bias correction\nfirst order polynomial of angle bias correction\n\nOn the other hand the predictors are saved in the diag files (see the Undestanding diag files section).\n\n\nCloud detection\nThe cloud pixel detection methodology depends on the wavelength of the observations. For microwave radiances, potentially cloud-contaminated observations are detected using scattering and Liquid Water Path (LWP) indices calculated from differences between different channels of each sensor (Weston et al. 2019; Zhu et al. 2016). For infrared channels, cloud contaminated observations are detected using the transmittance profile calculated by the CRTM model. In addition, GSI checks the difference between the observations and the simulated brightness temperature to detect cloudy pixels.\nA particular case is the ABI observations since the cloud mask (level 2 product) available at the same resolution as the observations is used. This cloud mask is generated by combining information from 8 channels of the ABI sensor from the spatial and temporal point of view.\n\n\nOther quality controls\nThe GSI quality control filters out those observations from channels close to the visible range over water surfaces with a zenith angle greater than 60\\(^{\\circ}\\) to reject those observations that could be contaminated by reflection. For infrared and microwave observations it also performs an emissivity check to detect observations contaminated by surface effects. Finally, a gross check is applied, i.e. the difference between the observation and the observation simulated by the model is compared with a predefined threshold depending on the observation error to reject erroneous observations."
   },
   {
     "objectID": "content/gsi/03-radiances.html#footnotes",
@@ -46,7 +46,7 @@
     "href": "content/gsi/01-gsi.html",
     "title": "The GSI assimilation system",
     "section": "",
-    "text": "The GSI (Gridpoint Statistical Interpolation) System, is a state-of-the-art data assimilation system initially developed by the Environmental Modeling Center at NCEP. It was designed as a traditional 3DVAR system applied in the gridpoint space of models to facilitate the implementation of inhomogeneous anisotropic covariances (Wu, Purser, and Parrish 2002; Purser et al. 2003b, 2003a). It is designed to run on various computational platforms, create analyses for different numerical forecast models, and remain flexible enough to handle future scientific developments, such as the use of new observation types, improved data selection, and new state variables (Kleist et al. 2009).\nThe- 3DVAR system replaced the NCEP regional grid-point operational analysis system by the North American Mesoscale Prediction System (NAM) in 2006 and the Spectral Statistical Interpolation (SSI) global analysis system used to generate Global Forecast System (GFS) initial conditions in 2007 (Kleist et al. 2009). In recent years, GSI has evolved to include various data assimilation techniques for multiple operational applications, including 2DVAR [e.g., the Real-Time Mesoscale Analysis (RTMA) system; Pondeca et al. (2011)], the hybrid EnVar technique (e.g., data assimilation systems for the GFS, the Rapid Refresh system (RAP), the NAM, the HWRF, etc. ), and 4DVAR [e.g., the data assimilation system for NASA’s Goddard Earth Observing System, version 5 (GEOS-5); Zhu and Gelaro (2008)]. GSI also includes a hybrid 4D-EnVar approach that is currently used for GFS generation.\nIn addition to the development of hybrid techniques, GSI allows the use of ensemble assimilation methods. To achieve this, it uses the same observation operator as the variational methods to compare the preliminary field or background with the observations. In this way the exhaustive quality controls developed for variational methods are also applied in ensemble assimilation methods. The EnKF code was developed by the Earth System Research Lab (ESRL) of the National Oceanic and Atmospheric Administration (NOAA) in collaboration with the scientific community. It contains two different algorithms for calculating the analysis increment, the serial Ensemble Square Root Filter (EnSRF, Whitaker and Hamill 2002) and the LETKF (Hunt, Kostelich, and Szunyogh 2007) contributed by Yoichiro Ota of the Japan Meteorological Agency (JMA).\nTo reduce the impact of spurious covariances on the increment applied to the analysis, ensemble systems apply a localization to the covariance matrix of the errors of the observations \\(R\\) in both the horizontal and vertical directions. GSI uses a polynomial of order 5 to reduce the impact of each observation gradually until a limiting distance is reached at which the impact is zero. The vertical location scale is defined in terms of the logarithm of the pressure and the horizontal scale is usually defined in kilometers. These parameters are important in obtaining a good analysis and depend on factors such as the size of the ensemble and the resolution of the model.\nGSI uses the Community Radiative Transfer Model (CRTM, Liu et al. 2008) as an operator for the radiance observations that calculates the brightness temperature simulated by the model in order to compare it with satellite sensor observations. GSI also implements a bias correction algorithm for the satellite radiance observations. The preliminary field estimate with the CRMT is compared with the radiance observations to obtain the innovation. This innovation is then used to calculate a bias that is applied to an updated innovation. This process can be repeated several times until the innovation and the bias correction coefficients converge."
+    "text": "The GSI (Gridpoint Statistical Interpolation) System, is a state-of-the-art data assimilation system initially developed by the Environmental Modeling Center at NCEP. It was designed as a traditional 3DVAR system applied in the gridpoint space of models to facilitate the implementation of inhomogeneous anisotropic covariances (Wu, Purser, and Parrish 2002; Purser et al. 2003b, 2003a). It is designed to run on various computational platforms, create analyses for different numerical forecast models, and remain flexible enough to handle future scientific developments, such as the use of new observation types, improved data selection, and new state variables (Kleist et al. 2009).\nThe 3DVAR system replaced the NCEP regional grid-point operational analysis system by the North American Mesoscale Prediction System (NAM) in 2006 and the Spectral Statistical Interpolation (SSI) global analysis system used to generate Global Forecast System (GFS) initial conditions in 2007 (Kleist et al. 2009). In recent years, GSI has evolved to include various data assimilation techniques for multiple operational applications, including 2DVAR [e.g., the Real-Time Mesoscale Analysis (RTMA) system; Pondeca et al. (2011)], the hybrid EnVar technique (e.g., data assimilation systems for the GFS, the Rapid Refresh system (RAP), the NAM, the HWRF, etc. ), and 4DVAR [e.g., the data assimilation system for NASA’s Goddard Earth Observing System, version 5 (GEOS-5); Zhu and Gelaro (2008)]. GSI also includes a hybrid 4D-EnVar approach that is currently used for GFS generation.\nIn addition to the development of hybrid techniques, GSI allows the use of ensemble assimilation methods. To achieve this, it uses the same observation operator as the variational methods to compare the preliminary field or background with the observations. In this way the exhaustive quality controls developed for variational methods are also applied in ensemble assimilation methods. The EnKF code was developed by the Earth System Research Lab (ESRL) of the National Oceanic and Atmospheric Administration (NOAA) in collaboration with the scientific community. It contains two different algorithms for calculating the analysis increment, the serial Ensemble Square Root Filter (EnSRF, Whitaker and Hamill 2002) and the LETKF (Hunt, Kostelich, and Szunyogh 2007) contributed by Yoichiro Ota of the Japan Meteorological Agency (JMA).\nTo reduce the impact of spurious covariances on the increment applied to the analysis, ensemble systems apply a localization to the covariance matrix of the errors of the observations \\(R\\) in both the horizontal and vertical directions. GSI uses a polynomial of order 5 to reduce the impact of each observation gradually until a limiting distance is reached at which the impact is zero. The vertical localization scale is defined in terms of the logarithm of the pressure and the horizontal scale is usually defined in kilometers. These parameters are important in obtaining a good analysis and depend on factors such as the size of the ensemble and the resolution of the model.\nGSI uses the Community Radiative Transfer Model (CRTM, Liu et al. 2008) as an operator for the radiance observations that calculates the brightness temperature simulated by the model in order to compare it with satellite observations. GSI also implements a bias correction algorithm for the satellite radiance observations. The preliminary field estimated with CRMT is compared with the radiance observations to obtain the innovation. This innovation is then used to calculate a bias that is then applied to an updated innovation. This process can be repeated several times until the innovation and the bias correction coefficients converge."
   },
   {
     "objectID": "content/gsi/01-gsi.html#available-observations-for-assimilation",
@@ -60,14 +60,14 @@
     "href": "content/gsi/01-gsi.html#running-gsi",
     "title": "The GSI assimilation system",
     "section": "Running GSI",
-    "text": "Running GSI\nEvery assimilation cycle starts with the background, a forecast generated using a numerical model (WRF-ARW for this guide), that was initialized from previous analysis and observations (in bufr format) that enters the GSI system. GSI will also need “fixed” files with information about the observations. This files define which observations are going to be assimilated, they errors and quality control options.\n\n\n\nDiagram of an assimilation cycle\n\n\nGSI can also be used with the following background files:\n\nWRF-NMM input fields in binary format\nWRF-NMM input fields in NetCDF format\nWRF-ARW input fields in binary format\nWRF-ARW input fields in NetCDF format\nGFS input fields in binary format or through NEMS I/O\nNEMS-NMMB input fields\nRTMA input files (2-dimensional binary format)\nWRF-Chem GOCART input fields with NetCDF format\nCMAQ binary file\n\nAnd the official tutorials are a good starting point to grasp the use of this options.\nGSI can also be run without observations to test the code, this is with a single synthetic observation defined in the SINGLEOB_TEST section in the namelist.\nThe fixed files are located in the fix/ folder and includes statistic files, configuration files, bias correction files, and CRTM coefficient files1. The information of the configuration files is saved in the output files after running GSI.\n\n\n\n\n\n\n\n\nGSI Name\nContent\nFile names\n\n\n\n\nanavinfo\nInformation file to set control and analysis variables\nanavinfo_arw_netcdf\n\n\nberror_stats\nbackground error covariance (for variacional methods)\nnam_nmmstat_na.gcv, nam_glb_berror.f77.gcv,\n\n\nerrtable\nObservation error table\nprepobs_errtable.global\n\n\nconvinfo\nConventional observation information file\nglobal_convinfo.txt\n\n\nsatinfo\nsatellite channel information file\nglobal_satinfo.txt\n\n\npcpinfo\nprecipitation rate observation information file\nglobal_pcpinfo.txt\n\n\nozinfo\nozone observation information file\nglobal_ozinfo.txt\n\n\nsatbias_angle\nsatellite scan angle dependent bias correction file\nglobal_satangbias.txt\n\n\nsatbias_in\nsatellite mass bias correction coefficient file\nsample.satbias\n\n\nsatbias_in\ncombined satellite angle dependent and mass bias correction coefficient file\ngdas1.t00z.abias.new"
+    "text": "Running GSI\nEvery assimilation cycle starts with the background, a forecast generated using a numerical model (WRF-ARW for this guide), that was initialized from previous analysis and observations (in bufr format) that enters the GSI system. GSI will also need “fixed” files with information about the observations. This “fix” files define which observations are going to be assimilated, they errors and quality control options.\n\n\n\nDiagram of an assimilation cycle\n\n\nGSI can also be used with the following background files:\n\nWRF-NMM input fields in binary format\nWRF-NMM input fields in NetCDF format\nWRF-ARW input fields in binary format\nWRF-ARW input fields in NetCDF format\nGFS input fields in binary format or through NEMS I/O\nNEMS-NMMB input fields\nRTMA input files (2-dimensional binary format)\nWRF-Chem GOCART input fields with NetCDF format\nCMAQ binary file\n\nAnd the official tutorials in the DTCenter webpage are a good starting point to grasp the use of this options.\nGSI can also be run without observations to test the code, this is with a single synthetic observation defined in the SINGLEOB_TEST section in the gsi namelist. Another thing to try at the beginning.\nThe fixed files are located in the fix/ folder and includes statistic files, configuration files, bias correction files, and CRTM coefficient files1. The information of the configuration files is saved in the output files after running GSI.\n\n\n\n\n\n\n\n\nGSI Name\nContent\nFile names\n\n\n\n\nanavinfo\nInformation file to set control and analysis variables\nanavinfo_arw_netcdf\n\n\nberror_stats\nbackground error covariance (for variacional methods)\nnam_nmmstat_na.gcv, nam_glb_berror.f77.gcv,\n\n\nerrtable\nObservation error table\nprepobs_errtable.global\n\n\nconvinfo\nConventional observation information file\nglobal_convinfo.txt\n\n\nsatinfo\nSatellite channel information file\nglobal_satinfo.txt\n\n\npcpinfo\nPrecipitation rate observation information file\nglobal_pcpinfo.txt\n\n\nozinfo\nOzone observation information file\nglobal_ozinfo.txt\n\n\nsatbias_angle\nSatellite scan angle dependent bias correction file\nglobal_satangbias.txt\n\n\nsatbias_in\nSatellite mass bias correction coefficient file\nsample.satbias\n\n\nsatbias_in\nCombined satellite angle dependent and mass bias correction coefficient file\ngdas1.t00z.abias.new"
   },
   {
     "objectID": "content/gsi/01-gsi.html#about-the-gsi-code",
     "href": "content/gsi/01-gsi.html#about-the-gsi-code",
     "title": "The GSI assimilation system",
     "section": "About the GSI code",
-    "text": "About the GSI code\nGSI is writen in fortran and the code is separated in more than 5 hundred files. While GSI has 2 good user guides, not everything is documented and sometimes you will need to read the code.\nTo swim around the code I found the grep -r \"key word\" command very useful. Each file and subroutine inside it has a header with information about what it does, changes and input and output arguments. It’s worth mentioning a few key files:\n\ngsimain.f90 and gsimod.f90 are the main files that control the system. gsimain.f90 has a list off code errors and the possible cause.\n*info.f90 like convinfo.f90 and radinfo.f90 are the routines that read the configuration files. Note that the satinfo file is read by the radinfo.f90 subroutine.\nread_*.f90 are a family of routines every bufr file that GSI is prepared to work with. For example there is a read_prepbufr.f90 and a read_goesimg.f90 that read goes observations including ABI.\nAnother important family of files is setup*.f90, these files process each variable to be assimilated. For example, setupt.f90 will:\n\nreads temperature obs assigned to given mpi task (geographic region),\nsimulates obs from guess,\napply some quality control to obs,\nload weight and innovation arrays used in minimization\ncollects statistics for runtime diagnostic output\nwrites additional diagnostic information to output file\n\nqcmod.f90 includes important routines for the quality control of radiance observations.\n\nThe mail files associated to the enkf code are:\n\nenkf.f90 and enkf_main.f90\nread*.f90 are the family of files that read the diag files generated by the observation operator.\nradbias.f90 manage the bias correction for radiance observation."
+    "text": "About the GSI code\nGSI is written in fortran and the code is separated in more than 5 hundred files. While GSI has 2 good user guides, not everything is documented and sometimes you will need to read the code.\nTo swim around the code I found the grep -r \"key word\" command very useful. Each file and subroutine inside it has a header with information about what it does, changes and input and output arguments. It’s worth mentioning a few key files:\n\ngsimain.f90 and gsimod.f90 are the main files that control the system. gsimain.f90 has a list off code errors and the possible cause.\n*info.f90 like convinfo.f90 and radinfo.f90 are the routines that read the configuration files. Note that the satinfo file is read by the radinfo.f90 subroutine.\nread_*.f90 are a family of routines every bufr file that GSI is prepared to work with. For example there is a read_prepbufr.f90 and a read_goesimg.f90 that read goes observations including ABI.\nAnother important family of files is setup*.f90, these files process each variable to be assimilated. For example, setupt.f90 will:\n\nreads temperature obs assigned to given mpi task (geographic region),\nsimulates obs from guess,\napply some quality control to obs,\nload weight and innovation arrays used in minimization\ncollects statistics for runtime diagnostic output\nwrites additional diagnostic information to output file\n\nqcmod.f90 includes important routines for the quality control of radiance observations.\n\nThe mail files associated to the enkf code are:\n\nenkf.f90 and enkf_main.f90\nread*.f90 are the family of files that read the diag files generated by the observation operator.\nradbias.f90 manage the bias correction for radiance observation."
   },
   {
     "objectID": "content/gsi/01-gsi.html#footnotes",
@@ -81,63 +81,63 @@
     "href": "content/gsi/04-diagfiles.html",
     "title": "Undestanding diag(nostic) files",
     "section": "",
-    "text": "The diag_&lt;obs&gt; files save the key information of how the observations where assimilated (with the variational method) or are going to be assimilated (using Kalman Filter), including the innovation (observation minus background), observation values, observation error and adjusted observation error, and quality control information.\nIt is important to check that the write_diag option in the GSI namelist is setup to .true..\nBy default the diag files are saved in binary format, and while GSI should be able to saved them as netcdfs, I have never made it work. So, this section will concentrate on how to decode the binary files and how to interpret the information.\nHere is a list of the files you get if you run GSI as observation operator, in this case we are assimilating AMSU-A observation from the NOAA-18 and METOP-A satellites, ABI observations from GOES-16 and conventional observations. To be able to use this output with the Kalman Filter methods we need the diag files for the ensemble mean and every member.\ndiag_abi_g16_ges.ensmean\ndiag_abi_g16_ges.mem001\ndiag_abi_g16_ges.mem002\ndiag_abi_g16_ges.mem003\ndiag_abi_g16_ges.mem004\ndiag_abi_g16_ges.mem005\ndiag_abi_g16_ges.mem006\ndiag_abi_g16_ges.mem007\ndiag_abi_g16_ges.mem008\ndiag_abi_g16_ges.mem009\ndiag_abi_g16_ges.mem010\ndiag_amsua_metop-a_ges.ensmean\ndiag_amsua_metop-a_ges.mem001\ndiag_amsua_metop-a_ges.mem002\ndiag_amsua_metop-a_ges.mem003\ndiag_amsua_metop-a_ges.mem004\ndiag_amsua_metop-a_ges.mem005\ndiag_amsua_metop-a_ges.mem006\ndiag_amsua_metop-a_ges.mem007\ndiag_amsua_metop-a_ges.mem008\ndiag_amsua_metop-a_ges.mem009\ndiag_amsua_metop-a_ges.mem010\ndiag_amsua_n18_ges.ensmean\ndiag_amsua_n18_ges.mem001\ndiag_amsua_n18_ges.mem002\ndiag_amsua_n18_ges.mem003\ndiag_amsua_n18_ges.mem004\ndiag_amsua_n18_ges.mem005\ndiag_amsua_n18_ges.mem006\ndiag_amsua_n18_ges.mem007\ndiag_amsua_n18_ges.mem008\ndiag_amsua_n18_ges.mem009\ndiag_amsua_n18_ges.mem010\ndiag_conv_ges.ensmean\ndiag_conv_ges.mem001\ndiag_conv_ges.mem002\ndiag_conv_ges.mem003\ndiag_conv_ges.mem004\ndiag_conv_ges.mem005\ndiag_conv_ges.mem006\ndiag_conv_ges.mem007\ndiag_conv_ges.mem008\ndiag_conv_ges.mem009\ndiag_conv_ges.mem010\nGSI includes some fortran routines you can use to decode the binary files. In may case I decided to modify those routines to get the information as a tidy table (1 observation per row, variables in columns) and to include more details present in the diagfiles.\nThe code is published in this repository, that includes a version of GSI with some modidications:\nread_diag/\n├── convinfo\n├── namelist.conv\n├── namelist.rad\n├── read_diag_conv_mean.sh\n├── read_diag_conv.sh\n├── read_diag_conv.x\n├── read_diag_rad_mean.sh\n├── read_diag_rad.sh\n├── read_diag_rad.x\n└── src\n    ├── compile_gcc\n    ├── compile_ifort\n    ├── read_diag_conv.f90\n    ├── read_diag_conv.f90_original\n    ├── read_diag_rad.f90\n    └── read_diag_rad.f90_original\nThere are 2 fortran routines, read_diag_conv.f90 for conventional diag files and read_diag_rad.f90 for radiances. To compile the routines it is necessary to link them with the libraries that GSI uses. An example of how to compile the code can be found in compile_gcc and compile_ifort.\nThe resulting executables are read_diag_conv.x and read_diag_rad.x. Each one is asociated to a namelist that you need to modify each time in order to run the code and decode an especific diagfile. See for example the content of namelist.conv:\n&iosetup\n  infilename='/home/paola.corrales/datosmunin3/EXP/E6_long/ANA/20181112220000/diagfiles/diag_conv_ges.ensmean',\n  outfilename='/home/paola.corrales/datosmunin3/EXP/E6_long/ANA/20181112220000/diagfiles/asim_conv_20181112220000.ensmean',\n /\nThe namelist is very simple, it only need the path to the diag file and the path to the output: a plain text file. But if you need to do this for every diag file, it is very time consuming. For that reason I wrote in bash some loops to go through all the diagfiles and decode them automatically. There are 4 bash files, to decode conventional diagfiles (ensemble mean or the members of the ensemble) and 2 for the radiance diagfiles. I’ve also kept the original fortran routines just in case.\n\nConventional obs\nThis is the information you get when you decode a conventional diagfile using the read_diag_conv.x:\n\nvariable\nstationID\ntype (acording to the prepbufr)\ndhr (difference between the obserbation time and the analysis time)\nlatitude\nlongitude\npressure\nusage flag (defined by gsi)\nusage flag preprepbufr\nobservation\nobservation minus guess\nobservation (only of uv)\nobservation minus guess (only of uv)\nobservation error\n\nEach row is an observation, except for wind that has u and v components in the same row.\n ps @ SCVD     : 187     -0.50  -39.61  286.94   0.101E+04    1    0   0.101E+04  -0.142E+01   0.100E+11   0.181E+03   0.161E+01\n ps @ 85782    : 181     -0.50  -40.60  286.95   0.999E+03    1    0   0.999E+03  -0.176E+01   0.100E+11   0.181E+03   0.227E+01\n ps @ 85766    : 181     -0.50  -39.65  287.92   0.101E+04    1    0   0.101E+04  -0.139E+00   0.100E+11   0.187E+03   0.295E+01\n  t @ 85782    : 181     -0.50  -40.60  286.95   0.999E+03    1    0   0.291E+03   0.242E+01   0.100E+11   0.181E+03   0.192E+01\n  t @ 85766    : 181     -0.50  -39.65  287.92   0.101E+04    1    0   0.291E+03   0.496E+01   0.100E+11   0.187E+03   0.100E+11\n  t @ SCJO     : 187     -0.50  -40.60  286.95   0.997E+03    1    0   0.291E+03   0.212E+01   0.100E+11   0.000E+00   0.150E+01\n  q @ SCVD     : 187     -0.50  -39.61  286.94   0.100E+04    1    0   0.113E-01   0.102E-02   0.114E-01   0.100E+11   0.228E-02\n  q @ 85782    : 181     -0.50  -40.60  286.95   0.999E+03    1    0   0.105E-01   0.946E-03   0.112E-01   0.100E+11   0.229E-02\n  q @ 85766    : 181     -0.50  -39.65  287.92   0.101E+04    1    0   0.110E-01   0.122E-02   0.995E-02   0.100E+11   0.988E-02\n  q @ SCJO     : 187     -0.50  -40.60  286.95   0.999E+03    1    0   0.107E-01   0.110E-02   0.112E-01   0.100E+11   0.225E-02\n uv @ IR270    : 245      0.00  -39.36  285.57   0.270E+03   -1  100   0.434E+02  -0.363E+01  -0.193E+02   0.614E+00   0.684E+01\n uv @ IR270    : 245      0.00  -39.31  286.11   0.269E+03   -1  100   0.434E+02  -0.225E+01  -0.193E+02  -0.108E+01   0.685E+01\nThe diag file includes more details. It may be useful to read the subroutine that write the diag files. The subroutine is called contents_binary_diag_ and is present in each setup*.f90 file. But here is a tip, it is much easier to read the contents_netcdf_diag_ subroutine because it mention the name of each variable to create the metadata of the netcdf file.\n\n\nRadiance obs\nFor radiances we’ll get a diag file for each sensor and satellite. But the structure of the binary files is always the same. Here is the list of variable I save from the diagfiles:\n\nsensor\nchannel\nfrequency\nlatitude\nlongitude\nelevation at observation location according guess (mb)\npressure at max of weighting function (mb)\ndhr (difference between the observation time and the analysis time)\nobservation (BT)\nobservation minus guess with bias correction\nobservation minus guess without bias correction\ninverse observation error\nquality control flag\nemissivity from surface\nstability index\nsatellite zenith angle (degrees)\nsatellite azimuth angle (degrees)\nfractional coverage by land\nfractional coverage by ice\nfractional coverage by ice\ncloud fraction (%)\ncloud top pressure (hPa)\npredictor 1\npredictor 2\npredictor 3\npredictor 4\npredictor 5\npredictor 6\npredictor 7\npredictor 8\npredictor 9\npredictor 10\npredictor 11\npredictor 12\n\nAgain, it is worth cheeking the subroutine that write the diagfiles for radiances, in case there are other details you need to include in the decodification.\nread_diag_rad.x will write a plain text file with all the variables listed above for each observation (from each satellite/sensor/channel).\n\n\nImportant information in the diagfiles\nWhile all variables included in the diagfiles are necessary for the assimilation, there are a few that I found particularly important to monitor the assimilation process:\n\nobservation minus guess: this variable should have a normal distribution centered in zero. If a bias correction was perform, it is important to compare the distribution with and without bias correction.\nquality control flag: if this variable is not zero, the observation will be rejected during the assimilation. To understand why this happened you need to check the GSI code and find the corresponding qc value. It will be different for each type of observation.\nerror: this variable is also used to decide if the observation will be assimilated or not. If the value is to big (and remember, GSI changes the value of the error depending on the quality of the observation), it means that the observation is not good."
+    "text": "The diag_&lt;obs&gt; files save the key information of how the observations where assimilated (with the variational method) or are going to be assimilated (using Kalman Filter), including the innovation (observation minus background), observation values, observation error and adjusted observation error, and quality control information.\nIt is important to check that the write_diag option in the GSI namelist is setup to .true..\nBy default the diag files are saved in binary format, and while GSI should be able to saved them as netCDFs, I have never made it work. So, this section will concentrate on how to decode the binary files and how to interpret the information.\nHere is a list of the files you get if you run GSI as observation operator, in this case we are assimilating AMSU-A observation from the NOAA-18 and METOP-A satellites, ABI observations from GOES-16 and conventional observations. To be able to use this output with the Kalman Filter methods we need the diag files for the ensemble mean and each member.\ndiag_abi_g16_ges.ensmean\ndiag_abi_g16_ges.mem001\ndiag_abi_g16_ges.mem002\ndiag_abi_g16_ges.mem003\ndiag_abi_g16_ges.mem004\ndiag_abi_g16_ges.mem005\ndiag_abi_g16_ges.mem006\ndiag_abi_g16_ges.mem007\ndiag_abi_g16_ges.mem008\ndiag_abi_g16_ges.mem009\ndiag_abi_g16_ges.mem010\ndiag_amsua_metop-a_ges.ensmean\ndiag_amsua_metop-a_ges.mem001\ndiag_amsua_metop-a_ges.mem002\ndiag_amsua_metop-a_ges.mem003\ndiag_amsua_metop-a_ges.mem004\ndiag_amsua_metop-a_ges.mem005\ndiag_amsua_metop-a_ges.mem006\ndiag_amsua_metop-a_ges.mem007\ndiag_amsua_metop-a_ges.mem008\ndiag_amsua_metop-a_ges.mem009\ndiag_amsua_metop-a_ges.mem010\ndiag_amsua_n18_ges.ensmean\ndiag_amsua_n18_ges.mem001\ndiag_amsua_n18_ges.mem002\ndiag_amsua_n18_ges.mem003\ndiag_amsua_n18_ges.mem004\ndiag_amsua_n18_ges.mem005\ndiag_amsua_n18_ges.mem006\ndiag_amsua_n18_ges.mem007\ndiag_amsua_n18_ges.mem008\ndiag_amsua_n18_ges.mem009\ndiag_amsua_n18_ges.mem010\ndiag_conv_ges.ensmean\ndiag_conv_ges.mem001\ndiag_conv_ges.mem002\ndiag_conv_ges.mem003\ndiag_conv_ges.mem004\ndiag_conv_ges.mem005\ndiag_conv_ges.mem006\ndiag_conv_ges.mem007\ndiag_conv_ges.mem008\ndiag_conv_ges.mem009\ndiag_conv_ges.mem010\nGSI includes some fortran routines you can use to decode the binary files. In my case I decided to modify those routines to get the information as a tidy table (1 observation per row, variables in columns) and to include more details present in the diagfiles.\nThe code is published in this repository, that includes a version of GSI with my modifications:\nread_diag/\n├── convinfo\n├── namelist.conv\n├── namelist.rad\n├── read_diag_conv_mean.sh\n├── read_diag_conv.sh\n├── read_diag_conv.x\n├── read_diag_rad_mean.sh\n├── read_diag_rad.sh\n├── read_diag_rad.x\n└── src\n    ├── compile_gcc\n    ├── compile_ifort\n    ├── read_diag_conv.f90\n    ├── read_diag_conv.f90_original\n    ├── read_diag_rad.f90\n    └── read_diag_rad.f90_original\nThere are 2 fortran routines, read_diag_conv.f90 for conventional diag files and read_diag_rad.f90 for radiances. To compile the routines it is necessary to link them with the libraries that GSI uses. An example of how to compile the code can be found in compile_gcc and compile_ifort.\nThe resulting executables are read_diag_conv.x and read_diag_rad.x. Each one is associated to a namelist that you need to modify each time in order to run the code and decode an specific diagfile. See for example the content of namelist.conv:\n&iosetup\n  infilename='/home/paola.corrales/datosmunin3/EXP/E6_long/ANA/20181112220000/diagfiles/diag_conv_ges.ensmean',\n  outfilename='/home/paola.corrales/datosmunin3/EXP/E6_long/ANA/20181112220000/diagfiles/asim_conv_20181112220000.ensmean',\n /\nThe namelist is very simple, it only need the path to the diag file and the path to the output: a plain text file. But if you need to do this for every diag file, it is very time consuming. For that reason I wrote in bash some loops to go through all the diagfiles and decode them automatically. There are 4 bash files, 2 to decode conventional diagfiles (ensemble mean or the members of the ensemble) and 2 for the radiance diagfiles. I’ve also kept the original fortran routines just in case.\n\nConventional obs\nThis is the information you get when you decode a conventional diagfile using the read_diag_conv.x:\n\nvariable\nstationID\ntype (according to the prepbufr)\ndhr (difference between the observation time and the analysis time)\nlatitude\nlongitude\npressure\nusage flag (defined by gsi)\nusage flag preprepbufr\nobservation\nobservation minus guess\nobservation (only if uv)\nobservation minus guess (only if uv)\nobservation error\n\nEach row is an observation, except for wind that has u and v components in the same row.\n ps @ SCVD     : 187     -0.50  -39.61  286.94   0.101E+04    1    0   0.101E+04  -0.142E+01   0.100E+11   0.181E+03   0.161E+01\n ps @ 85782    : 181     -0.50  -40.60  286.95   0.999E+03    1    0   0.999E+03  -0.176E+01   0.100E+11   0.181E+03   0.227E+01\n ps @ 85766    : 181     -0.50  -39.65  287.92   0.101E+04    1    0   0.101E+04  -0.139E+00   0.100E+11   0.187E+03   0.295E+01\n  t @ 85782    : 181     -0.50  -40.60  286.95   0.999E+03    1    0   0.291E+03   0.242E+01   0.100E+11   0.181E+03   0.192E+01\n  t @ 85766    : 181     -0.50  -39.65  287.92   0.101E+04    1    0   0.291E+03   0.496E+01   0.100E+11   0.187E+03   0.100E+11\n  t @ SCJO     : 187     -0.50  -40.60  286.95   0.997E+03    1    0   0.291E+03   0.212E+01   0.100E+11   0.000E+00   0.150E+01\n  q @ SCVD     : 187     -0.50  -39.61  286.94   0.100E+04    1    0   0.113E-01   0.102E-02   0.114E-01   0.100E+11   0.228E-02\n  q @ 85782    : 181     -0.50  -40.60  286.95   0.999E+03    1    0   0.105E-01   0.946E-03   0.112E-01   0.100E+11   0.229E-02\n  q @ 85766    : 181     -0.50  -39.65  287.92   0.101E+04    1    0   0.110E-01   0.122E-02   0.995E-02   0.100E+11   0.988E-02\n  q @ SCJO     : 187     -0.50  -40.60  286.95   0.999E+03    1    0   0.107E-01   0.110E-02   0.112E-01   0.100E+11   0.225E-02\n uv @ IR270    : 245      0.00  -39.36  285.57   0.270E+03   -1  100   0.434E+02  -0.363E+01  -0.193E+02   0.614E+00   0.684E+01\n uv @ IR270    : 245      0.00  -39.31  286.11   0.269E+03   -1  100   0.434E+02  -0.225E+01  -0.193E+02  -0.108E+01   0.685E+01\nThe diag file includes more details. It may be useful to read the subroutine that write the diag files. The subroutine is called contents_binary_diag_ and is present in each setup*.f90 file. But here is a tip, it is much easier to read the contents_netcdf_diag_ subroutine because it mention the name of each variable to create the metadata of the netCDF file.\n\n\nRadiance obs\nFor radiances we’ll get a diag file for each sensor and satellite. But the structure of the binary files is always the same. Here is the list of variable I save from the diagfiles:\n\nsensor\nchannel\nfrequency\nlatitude\nlongitude\nelevation at observation location according guess (mb)\npressure at max of weighting function (mb)\ndhr (difference between the observation time and the analysis time)\nobservation (BT)\nobservation minus guess with bias correction\nobservation minus guess without bias correction\ninverse observation error\nquality control flag\nemissivity from surface\nstability index\nsatellite zenith angle (degrees)\nsatellite azimuth angle (degrees)\nfractional coverage by land\nfractional coverage by ice\nfractional coverage by ice\ncloud fraction (%)\ncloud top pressure (hPa)\npredictor 1\npredictor 2\npredictor 3\npredictor 4\npredictor 5\npredictor 6\npredictor 7\npredictor 8\npredictor 9\npredictor 10\npredictor 11\npredictor 12\n\nAgain, it is worth cheeking the subroutine that write the diagfiles for radiances, in case there are other details you need to include in the decodification.\nread_diag_rad.x will write a plain text file with all the variables listed above for each observation (from each satellite/sensor/channel).\n\n\nImportant information in the diagfiles\nWhile all variables included in the diagfiles are necessary for the assimilation, there are a few that I found particularly important to monitor the assimilation process:\n\nobservation minus guess: this variable should have a normal distribution centered in zero. If a bias correction was perform, it is important to compare the distribution with and without bias correction.\nquality control flag: if this variable is not zero, the observation will be rejected during the assimilation. To understand why this happened you need to check the GSI code and find the corresponding qc value. It will be different for each type of observation.\nerror: this variable is also used to decide if the observation will be assimilated or not. If the value is to big (and remember, GSI changes the value of the error depending on the quality of the observation), it means that the observation is not good."
   },
   {
     "objectID": "content/observations/03-rad-bufr.html",
     "href": "content/observations/03-rad-bufr.html",
     "title": "Radiance obs bufr",
     "section": "",
-    "text": "If you’ve read the previous sections, you know that working with bufr files is not easy. It is possible by now that the bufr files for ABI observations (from GOES satellites) are available everywhere. But if you try to run assimilation experiments for “old” cases like me you will need to convert the observations in netCDF to the bufr format. So, this section explains how to do that.\nThe routine I used is based on a a routine written by Jamie Bresch from NCAR/MMM. I made a few modifications to work with the current GSI version.\nIt read the netCDF metadata from the files listed in flist.txt (usually 1 per channel) and the cloud mask. Then, it calculate geometric/geographic variables like longitude, latitude, the projection, the zenith angle of the sun on that specific time, etc.\nAfter that it will read each variable, calculate the brightness temperature from radiance and the standard deviation of the brightness temperature at each point. It will then write the bufr file using the bufrtab_NC021046.txt table.\nLike the other bufr routines, it uses a namelist:"
+    "text": "If you’ve read the previous sections, you know that working with bufr files is not easy. It is possible by now that the bufr files for ABI observations (from GOES satellites) are available everywhere. But if you try to run assimilation experiments for “old” cases like me you will need to convert the observations in netCDF to bufr format. So, this section explains how to do that.\nThe routine I used is based on a a routine written by Jamie Bresch from NCAR/MMM. I made a few modifications to work with the current GSI version but it is essentially the same.\nIt read the netCDF metadata from the files listed in flist.txt (usually 1 file per channel and the cloud mask). Then, it calculate geometric/geographic variables like longitude, latitude, the projection, the zenith angle of the sun on that specific time, etc.\nAfter that it will read from the files each variable, calculate the brightness temperature from radiance and the standard deviation of the brightness temperature at each point. It will then write the bufr file using the bufrtab_NC021046.txt table.\nLike the other bufr routines, it uses a namelist:"
   },
   {
     "objectID": "content/observations/03-rad-bufr.html#the-code",
     "href": "content/observations/03-rad-bufr.html#the-code",
     "title": "Radiance obs bufr",
     "section": "The code",
-    "text": "The code\nThe source code is publicly available in this repository. The root folder includes a compile file as example of how to compile the program. It needs the bufr library to work and you can use the want that get compiled along with GSI.\nThe rundir folder includes all the configuration files, namelists and bufr tables. Once you compile the routine, you can try running an example using the example observations available in the example_obs folder. The flist.txt and namelist.goes_nc2bufr files are ready to work.\nFinally, if you ever need to do this for many files run_goesbufr.sh script will help you. It modify the namelist and run the programs in a loop.\ngoesbufr/\n├── compile.sh\n├── example_obs\n│   ├── OR_ABI-L1b-RadF-M3C07_G16_s20183170000345_e20183170011123_c20183170011157.nc\n│   ├── OR_ABI-L1b-RadF-M3C08_G16_s20183170000345_e20183170011111_c20183170011157.nc\n│   ├── OR_ABI-L1b-RadF-M3C09_G16_s20183170000345_e20183170011117_c20183170011172.nc\n│   ├── OR_ABI-L1b-RadF-M3C10_G16_s20183170000345_e20183170011123_c20183170011169.nc\n│   ├── OR_ABI-L1b-RadF-M3C11_G16_s20183170000345_e20183170011111_c20183170011168.nc\n│   ├── OR_ABI-L1b-RadF-M3C12_G16_s20183170000345_e20183170011117_c20183170011173.nc\n│   ├── OR_ABI-L1b-RadF-M3C13_G16_s20183170000345_e20183170011123_c20183170011175.nc\n│   ├── OR_ABI-L1b-RadF-M3C14_G16_s20183170000345_e20183170011111_c20183170011176.nc\n│   ├── OR_ABI-L1b-RadF-M3C15_G16_s20183170000345_e20183170011117_c20183170011176.nc\n│   ├── OR_ABI-L1b-RadF-M3C16_G16_s20183170000345_e20183170011123_c20183170011176.nc\n│   └── OR_ABI-L2-ACMF-M3_G16_s20183170000345_e20183170011111_c20183170011289.nc\n├── GOES16_nc2bufr.exe\n├── GOES_GRB_nc2bufr.f90\n├── GOES_GRB_nc2bufr.ori  # the original code\n└── rundir\n    ├── bufrtab_NC021046.txt\n    ├── flist.txt\n    ├── GOES16_nc2bufr.exe\n    ├── namelist.goes_nc2bufr\n    ├── run_goesbufr.sh\n    └── submit.csh\n\n\n\n\n\n\nImportant\n\n\n\nOnce again I want to acknowledge that the routine is based on a routine written by Jamie Bresch from NCAR/MMM. If you use it, please mention this guide and Jamie."
+    "text": "The code\nThe source code is publicly available in this repository. The root folder includes a compile file as example of how to compile the program. It needs the bufr library to work and you can use the one that get compiled along with GSI.\nThe rundir folder includes all the configuration files, namelists and bufr tables. Once you compile the routine, you can try running an example using the example observations available in the example_obs folder. The flist.txt and namelist.goes_nc2bufr files are ready to work.\nFinally, if you ever need to do this for many files run_goesbufr.sh script will help you. It modify the namelist and run the programs in a loop.\ngoesbufr/\n├── compile.sh\n├── example_obs\n│   ├── OR_ABI-L1b-RadF-M3C07_G16_s20183170000345_e20183170011123_c20183170011157.nc\n│   ├── OR_ABI-L1b-RadF-M3C08_G16_s20183170000345_e20183170011111_c20183170011157.nc\n│   ├── OR_ABI-L1b-RadF-M3C09_G16_s20183170000345_e20183170011117_c20183170011172.nc\n│   ├── OR_ABI-L1b-RadF-M3C10_G16_s20183170000345_e20183170011123_c20183170011169.nc\n│   ├── OR_ABI-L1b-RadF-M3C11_G16_s20183170000345_e20183170011111_c20183170011168.nc\n│   ├── OR_ABI-L1b-RadF-M3C12_G16_s20183170000345_e20183170011117_c20183170011173.nc\n│   ├── OR_ABI-L1b-RadF-M3C13_G16_s20183170000345_e20183170011123_c20183170011175.nc\n│   ├── OR_ABI-L1b-RadF-M3C14_G16_s20183170000345_e20183170011111_c20183170011176.nc\n│   ├── OR_ABI-L1b-RadF-M3C15_G16_s20183170000345_e20183170011117_c20183170011176.nc\n│   ├── OR_ABI-L1b-RadF-M3C16_G16_s20183170000345_e20183170011123_c20183170011176.nc\n│   └── OR_ABI-L2-ACMF-M3_G16_s20183170000345_e20183170011111_c20183170011289.nc\n├── GOES16_nc2bufr.exe\n├── GOES_GRB_nc2bufr.f90\n├── GOES_GRB_nc2bufr.ori  # the original code\n└── rundir\n    ├── bufrtab_NC021046.txt\n    ├── flist.txt\n    ├── GOES16_nc2bufr.exe\n    ├── namelist.goes_nc2bufr\n    ├── run_goesbufr.sh\n    └── submit.csh\n\n\n\n\n\n\nImportant\n\n\n\nOnce again I want to acknowledge that the routine is based on a routine written by Jamie Bresch from NCAR/MMM. If you use it, please mention this guide and Jamie."
   },
   {
     "objectID": "index.html",
     "href": "index.html",
-    "title": "DA-documentation",
+    "title": "Welcome!",
     "section": "",
-    "text": "This is a work in progress\n\n\n\nComeback later to see more or, if you want to contribute, open an issue in the associated repo.\nThis website compiles a series of tutorials, scripts and in general a comprehensive documentation around the GSI system V3.7 - EnKF V1.3. It focus on the use of GSI as a observation operator along with the LETKF version. It covers everything you need from how to deal with observations (in bufr format), how to configure the system to how read and interpret GSI outputs."
+    "text": "This website compiles a series of examples, tutorials, scripts and in general a comprehensive documentation around the GSI system V3.7 - EnKF V1.3. It focus on the use of GSI as a observation operator along with the EnKF version. It covers everything you need to know from how to deal with observations (in bufr format), how to configure the system to assimilate conventional and radiance observtions to how to read and interpret GSI outputs.\n\n\nWhile the text in this guide is released under a Creative Commons Attribution-ShareAlike 4.0 International License, specific scripts or programming routines may have different licences and authors. If you use the material in any way, make sure to check the note associated to each section and cite it appropriately.\n\n\n\nYou can cite this guide using its Zenodo metadata and DOI .\n\n\n\nAny contribution is welcome, please read this guide to learn how to do it."
   },
   {
     "objectID": "index.html#a-note-about-using-this-material",
     "href": "index.html#a-note-about-using-this-material",
-    "title": "DA-documentation",
-    "section": "A note about using this material",
-    "text": "A note about using this material\nWhile the text in this guide is released under a Creative Commons Attribution-ShareAlike 4.0 International License, specific scripts or programming routines may have different licences and authors. If you use the material in any way, make sure to check the Licence note associated to each section and cite it appropriately."
+    "title": "Welcome!",
+    "section": "",
+    "text": "While the text in this guide is released under a Creative Commons Attribution-ShareAlike 4.0 International License, specific scripts or programming routines may have different licences and authors. If you use the material in any way, make sure to check the note associated to each section and cite it appropriately."
   },
   {
     "objectID": "index.html#citing-this-guide",
     "href": "index.html#citing-this-guide",
-    "title": "DA-documentation",
-    "section": "Citing this guide",
-    "text": "Citing this guide\nYou can cite this guide using its Zenodo metadata and DOI ."
+    "title": "Welcome!",
+    "section": "",
+    "text": "You can cite this guide using its Zenodo metadata and DOI ."
   },
   {
     "objectID": "index.html#do-you-want-to-contribute",
     "href": "index.html#do-you-want-to-contribute",
-    "title": "DA-documentation",
-    "section": "Do you want to contribute?",
-    "text": "Do you want to contribute?\nAny contribution is welcome, please read this guide to learn how to do it."
+    "title": "Welcome!",
+    "section": "",
+    "text": "Any contribution is welcome, please read this guide to learn how to do it."
   },
   {
     "objectID": "about.html",
     "href": "about.html",
     "title": "About",
     "section": "",
-    "text": "This guide is a compilation of many tools scripts, pieces of code and routines that I used during my PhD. As the name says, everything goes around assimilating observations using the GSI system. I spent a lot of time working with the conventional and Radiance observations so you will find a comprehensive tutorial and documentation on how to assimilate these types of observations. This includes the processing of the observations, how to configure the system and all the quality control steps GSI performs during the assimilation process.\nSometimes you will find everything inside the website and sometimes you will need to go to a specific repository to get the code or the data associated with the the specific topic. And while I tried to be mindful during my PhD at commenting and documenting everything along the way I’m sure that there are gaps and missing pieces. If you find anything that can be improved please open an issue in the repository of this website and contribute to making this guide better.\nMany of these tools come from different sources. Sometimes someone else wrote the code and I adapted it to my specific needs, sometimes I wrote the code from scratch. So it’s important to read the license note in each section so you know who created that code and in which way you can use it."
+    "text": "I’m Pao Corrales and I have a PhD in Atmospheric Science! The main goal of my research was to applied data assimilation techniques to improve short-term forecasts of severe events in Argentina. In particular, the research focuses on data assimilation of observations from automatic stations and radiances from polar and geostationary satellites. You can read the final dissertation (in Spanish) here.\nI worked in the Centro de Investigaciones del Mar y la Atmósfera (CIMA), for that reason you may find mentions to Hydra or Yakaira, their HPC and a server I used a lot.\nThis guide is a compilation of many tools, scripts, pieces of code and routines that I used during my PhD. As the name says, everything goes around assimilating observations using the GSI system. I spent a lot of time working with the conventional and Radiance observations so you will find a comprehensive tutorial and documentation on how to assimilate these types of observations. This includes the processing of the observations, how to configure the system and all the quality control steps GSI performs during the assimilation process.\nSometimes you will find everything inside the website and sometimes you will need to go to a specific repository to get the code or the data associated with the the specific topic. And while I tried to be mindful during my PhD at commenting and documenting everything along the way I’m sure that there are gaps and missing pieces. If you find anything that can be improved please open an issue in the repository of this website and contribute to make this guide better.\nMany of these tools come from different sources. Sometimes someone else wrote the code and I adapted it to my specific needs, sometimes I wrote the code from scratch. So it’s important to read the license note in each section so you know who created that code and in which way you can use it."
   },
   {
-    "objectID": "about.html#about-my-phd",
-    "href": "about.html#about-my-phd",
+    "objectID": "about.html#hi",
+    "href": "about.html#hi",
     "title": "About",
-    "section": "About my PhD",
-    "text": "About my PhD\nThe main goal of may research was to applied data assimilation techniques to improve short-term forecasts of severe events in Argentina. In particular, the research focuses on data assimilation of observations from automatic stations and radiances from polar and geostationary satellites. You can read the final dissertation (in Spanish) here.\nI worked in the Centro de Investigaciones del Mar y la Atmósfera (CIMA), for that reason you may find mentions to Hydra or Yakaira, their HPC and a server I used a lot."
+    "section": "",
+    "text": "I’m Pao Corrales and I have a PhD in Atmospheric Science! The main goal of my research was to applied data assimilation techniques to improve short-term forecasts of severe events in Argentina. In particular, the research focuses on data assimilation of observations from automatic stations and radiances from polar and geostationary satellites. You can read the final dissertation (in Spanish) here.\nI worked in the Centro de Investigaciones del Mar y la Atmósfera (CIMA), for that reason you may find mentions to Hydra or Yakaira, their HPC and a server I used a lot.\nThis guide is a compilation of many tools, scripts, pieces of code and routines that I used during my PhD. As the name says, everything goes around assimilating observations using the GSI system. I spent a lot of time working with the conventional and Radiance observations so you will find a comprehensive tutorial and documentation on how to assimilate these types of observations. This includes the processing of the observations, how to configure the system and all the quality control steps GSI performs during the assimilation process.\nSometimes you will find everything inside the website and sometimes you will need to go to a specific repository to get the code or the data associated with the the specific topic. And while I tried to be mindful during my PhD at commenting and documenting everything along the way I’m sure that there are gaps and missing pieces. If you find anything that can be improved please open an issue in the repository of this website and contribute to make this guide better.\nMany of these tools come from different sources. Sometimes someone else wrote the code and I adapted it to my specific needs, sometimes I wrote the code from scratch. So it’s important to read the license note in each section so you know who created that code and in which way you can use it."
   },
   {
     "objectID": "contributors.html",
@@ -151,14 +151,14 @@
     "href": "content/observations/02-conv-bufr.html",
     "title": "Conventional obs bufr",
     "section": "",
-    "text": "This section covers how to add new surface observations to prepBUFR and how to divide a file into smaller subsets.\nOne of the first challenges (besides to learning how to use GSI and deal with bufr files) was to incorporate surface observations from automatic stations to the assimilation. In Argentina there are very few official stations to cover the entire country but there are private automatic station network that could potentially help to improve weather forecasts thank to their higher frequency (10 minutes) and spacial resolution.\nThis requires to incorporate these new observations (available at Garcia et al. 2019) to the prepBUFR (so, be able to write fortran code and understand the bufr format). The 2 programs included here are based on the INPE/CPTEC modules and programs that are part of their operational assimilation system. I was lucky to visit CPTEC in 2019 where I learned how to work with these tools."
+    "text": "This section covers how to add new surface observations to prepBUFR and how to divide a file into smaller subsets.\nOne of the first challenges (besides learning how to use GSI and deal with bufr files) was to incorporate surface observations from automatic stations to the assimilation. In Argentina there are very few official stations to cover the entire country but there are private automatic station network that could potentially help to improve weather forecasts thank to their higher frequency (10 minutes) and spacial resolution.\nThis requires to incorporate these new observations (available at Garcia et al. 2019) to the prepBUFR (so, be able to write fortran code and understand the bufr format). The 2 programs included here are based on the INPE/CPTEC modules and programs that are part of their operational assimilation system. I was lucky to visit CPTEC in 2019 where I learned how to work with these tools."
   },
   {
     "objectID": "content/observations/02-conv-bufr.html#add-observations-to-a-prepbufr-file",
     "href": "content/observations/02-conv-bufr.html#add-observations-to-a-prepbufr-file",
     "title": "Conventional obs bufr",
     "section": "Add observations to a prepBUFR file",
-    "text": "Add observations to a prepBUFR file\nIn the previous section I briefly explained how to read and write a bufr file. To add new observations to an existing file (o to a new file!) we use the same functions mentioned here and structure of the routine is also similar. But we also need to figure out how to read the new observations and how to create new reports.\nThe code I’m sharing here assume that the new observations are in csv format and has the following look:\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nLAT\nLON\nELV\nSTATION\nyyyymmddhhmmss\nTOB\nQOB\nUOB\nVOB\nPRSS\n\n\n\n\n-19.0124\n-65.2921\n2907\n“BLV102”\n20181111200000\n28.9\n0.00624936719941647\n0\n-2.88088888888889\n71950\n\n\n-17.4111\n-66.1744\n2548\n“BLV124”\n20181111200000\n29\n0.00636021217641851\n-3.27390439689371\n-3.27390439689372\n74280\n\n\n-16.8378\n-64.7925\n195\n“BLV141”\n20181111200000\n32.9\n0.0439748860789023\n-1.34593847427853\n-1.34593847427853\n50240\n\n\n-17.9747\n-67.08\n4057\n“BLV154”\n20181111201500\n19.2\n0.00317768840091676\n-6.08364406830543\n-2.51992788174274\n62030\n\n\n-17.6364\n-67.2003\n3798\n“BLV157”\n120181111200000\n19\n0.00626217287136847\n-5.34737718159307\n-5.34737718159307\n64460\n\n\n\n\n\n\n\n\n\nImportant\n\n\n\nIf you want to convert the files available here into csv tables, here is an R script to do that.\n\n\nThe program read the configuration file that define where is the namelist and the prepbufr table and call a function that start the process. The namelist will list the name of the prepbufr to modify and the csv files with the new observations. The most important subroutine is adpsfc_rw_prepbufr():\n\nReads the bufr file\nReads the csv with new observations\nDecides if the observations fall into the time window\nCreates a new report type 187\nWrite the bufr file\n\n\n\n\nadd_obs rutine flowchart"
+    "text": "Add observations to a prepBUFR file\nIn the previous section I briefly explained how to read and write a bufr file. To add new observations to an existing file (o to a new file!) we use the same functions mentioned here and structure of the routine is also similar. But we also need to figure out how to read the new observations into fortran and how to create new reports.\nThe code I’m sharing here assume that the new observations are in csv format and has the following look (without the header):\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nLAT\nLON\nELV\nSTATION\nyyyymmddhhmmss\nTOB\nQOB\nUOB\nVOB\nPRSS\n\n\n\n\n-19.0124\n-65.2921\n2907\n“BLV102”\n20181111200000\n28.9\n0.00624936719941647\n0\n-2.88088888888889\n71950\n\n\n-17.4111\n-66.1744\n2548\n“BLV124”\n20181111200000\n29\n0.00636021217641851\n-3.27390439689371\n-3.27390439689372\n74280\n\n\n-16.8378\n-64.7925\n195\n“BLV141”\n20181111200000\n32.9\n0.0439748860789023\n-1.34593847427853\n-1.34593847427853\n50240\n\n\n-17.9747\n-67.08\n4057\n“BLV154”\n20181111201500\n19.2\n0.00317768840091676\n-6.08364406830543\n-2.51992788174274\n62030\n\n\n-17.6364\n-67.2003\n3798\n“BLV157”\n120181111200000\n19\n0.00626217287136847\n-5.34737718159307\n-5.34737718159307\n64460\n\n\n\n\n\n\n\n\n\nImportant\n\n\n\nIf you want to convert the files available here into csv tables, I wrote an R script to do that.\n\n\nThe program read the configuration file (add_obs.conf) that define where is the namelist and the prepbufr table and call a function that start the process. The namelist will list the name of the prepbufr file to modify and the csv files with the new observations. The most important subroutine is adpsfc_rw_prepbufr() that:\n\nReads the bufr file\nReads the csv with new observations\nDecides if the observations fall into the time window\nCreates a new report type 187 (check obs types here)\nWrite the bufr file\n\n\n\n\nadd_obs rutine flowchart"
   },
   {
     "objectID": "content/observations/02-conv-bufr.html#filter-observations-in-a-prepbufr",
@@ -172,7 +172,7 @@
     "href": "content/observations/02-conv-bufr.html#the-code",
     "title": "Conventional obs bufr",
     "section": "The code",
-    "text": "The code\nThe source code is publicly available in this repository. Each source folder includes a compile file as example of how to compile the program. It needs the bufr and w3lib to work with times.\nThe run folder includes all the configuration files, namelists and bufr tables. The can be uses to run the programs using the example observations available in the example_obs folder.\nFinally, if you ever need to do this for many files, the run_bash folder has 2 bash scripts that modify the namelist and run the programs in a loop.\nprepbufr_tools\n├── example_obs\n│   ├── 2018111719.csv\n│   ├── 2018111720.csv\n│   ├── cimap.20181117.t20z.01h.prepbufr.nqc\n│   └── prepbufr.gdas.20181117.t18z.nr.48h\n├── README.md\n├── run\n│   ├── add_obs.conf\n│   ├── namelist_conv.PREPOBS\n│   ├── namelist_conv.PREPRW\n│   ├── prepbufr_gen.conf\n│   └── prepobs_prep.bufrtable\n├── run_bach\n│   ├── run_add_obs.sh\n│   └── run_filter_obs.sh\n├── src_add_obs\n│   ├── compile\n│   ├── m_adpsfc_rw.f90\n│   ├── main_add_obs.f90\n│   ├── m_convobs.f90\n│   ├── m_vars_global.f90\n└── src_filter_obs\n    ├── compile\n    ├── m_filter_obs.f90\n    ├── m_read_namelist.f90\n    ├── m_vars_global.f90\n    └── prepbufr_gen.f90\n\n\n\n\n\n\nImportant\n\n\n\nOnce again, this routines are based on the INPE/CPTEC modules and programs that are part of their operational assimilation system."
+    "text": "The code\nThe source code is publicly available in this repository. Each source folder includes a compile file as example of how to compile the program. It needs the bufr library to work with bufr files and w3lib library to work with times.\nThe run folder includes all the configuration files, namelists and bufr tables. They can be uses as it is to run the programs using the example observations available in the example_obs folder.\nFinally, if you ever need to do this many files, the run_bash folder has 2 bash scripts that modify the namelist and run the programs in a loop.\nprepbufr_tools\n├── example_obs\n│   ├── 2018111719.csv\n│   ├── 2018111720.csv\n│   ├── cimap.20181117.t20z.01h.prepbufr.nqc\n│   └── prepbufr.gdas.20181117.t18z.nr.48h\n├── README.md\n├── run\n│   ├── add_obs.conf\n│   ├── namelist_conv.PREPOBS\n│   ├── namelist_conv.PREPRW\n│   ├── prepbufr_gen.conf\n│   └── prepobs_prep.bufrtable\n├── run_bach\n│   ├── run_add_obs.sh\n│   └── run_filter_obs.sh\n├── src_add_obs\n│   ├── compile\n│   ├── m_adpsfc_rw.f90\n│   ├── main_add_obs.f90\n│   ├── m_convobs.f90\n│   ├── m_vars_global.f90\n└── src_filter_obs\n    ├── compile\n    ├── m_filter_obs.f90\n    ├── m_read_namelist.f90\n    ├── m_vars_global.f90\n    └── prepbufr_gen.f90\n\n\n\n\n\n\nImportant\n\n\n\nOnce again, this routines are based on the INPE/CPTEC modules and programs that are part of their operational assimilation system. I wouldn’t have been able to work with bufr files without the help and guidance of Luiz Sapucci and his team"
   },
   {
     "objectID": "content/observations/01-bufr.html",
@@ -193,42 +193,42 @@
     "href": "content/observations/01-bufr.html#an-introduction-on-how-to-read-and-write-bufr-files",
     "title": "Working with bufr files",
     "section": "An introduction on how to read and write BUFR files",
-    "text": "An introduction on how to read and write BUFR files\nWorking with BUFR files requires to work with fortran routines. Fortunately there is a library that contains subroutines, functions and other utilities that can be used to read (decode) and write (encode) data in BUFR: NCEPLIBS-bufr. This library is compiled during the compilation of GSI but can also be used independently.\nHere is a simplified example of a routine to decode a bufr file:\nopen(unit_in,file='sample.bufr',action='read',form='unformatted')\ncall openbf(unit_in,'IN',unit_in)\n  \n  msg_report: do while (ireadmg(unit_in,subset,idate) == 0)\n    \n    sb_report: do while (ireadsb(unit_in) == 0)\n\n      call ufbint(unit_in,hdr,3,1 ,iret,hdstr)\n      call ufbint(unit_in,obs,1,10,iret,obstr)\n\n    enddo sb_report\n  \n  enddo msg_report\n\ncall closbf(unit_in)\n\nThe first level of code open and close the file. It uses the openbf() and closebf()functions from the BUFR library.\nThe second level will read each message. Each loop reads in one message until the last message in the file is reached. It uses the ireadmg() function.\nThe third level will read the reports inside each message using the ireadsb().\nAnd finally inside each report, we access the data values using the ufbint() function. In this example we save the header in formation in one array and the observation information in a second array.\n\nGSI includes some example routines as part ad the bufr tools kit. A complete routine to decode a BUFR file can be found here. The routine to encode a BUFR file will have similar characteristics.\nAnd again, BUFR files will be different for different type of observations and you always need the associated mnemonics table.\n\nDecode prepBUFR files\nThis is not different that we’ve seen previously and the BUFR tools fonder in the GSI code has very good examples to use. But I like to have the data in tidy tables, so I’ve modified that code to decode a prepBUFR file into a table where each row is an observation. This is the routine:\nprogram prepbufr_decode_all_df\n!\n! read all observations out from prepbufr. \n! read bufr table from prepbufr file\n! output in a \"data frameish\" type \n!\n implicit none\n\n integer, parameter :: mxmn=35, mxlv=250\n character(80):: hdstr='SID XOB YOB DHR TYP ELV SAID T29'\n character(80):: obstr='POB QOB TOB ZOB UOB VOB PWO CAT PRSS'\n character(80):: qcstr='PQM QQM TQM ZQM WQM NUL PWQ     '\n character(80):: oestr='POE QOE TOE NUL WOE NUL PWE     '\n real(8) :: hdr(mxmn),obs(mxmn,mxlv),qcf(mxmn,mxlv),oer(mxmn,mxlv)\n\n INTEGER        :: ireadmg,ireadsb\n\n character(8)   :: subset\n integer        :: unit_in=10,idate,nmsg,ntb\n\n character(8)   :: c_sid\n real(8)        :: rstation_id\n equivalence(rstation_id,c_sid)\n\n integer        :: i,k,iret\n!\n!\n open(24,file='prepbufr.table')\n open(unit_in,file='prepbufr',form='unformatted',status='old')\n call openbf(unit_in,'IN',unit_in)\n call dxdump(unit_in,24)\n call datelen(10)\n   nmsg=0\n   msg_report: do while (ireadmg(unit_in,subset,idate) == 0)\n     nmsg=nmsg+1\n     ntb = 0\n\n     sb_report: do while (ireadsb(unit_in) == 0)\n       ntb = ntb+1\n       !write(*,*)'New secction: ',ntb,' in msg ',nmsg\n       call ufbint(unit_in,hdr,mxmn,1   ,iret,hdstr)\n       call ufbint(unit_in,obs,mxmn,mxlv,iret,obstr)\n       call ufbint(unit_in,oer,mxmn,mxlv,iret,oestr)\n       call ufbint(unit_in,qcf,mxmn,mxlv,iret,qcstr)\n       rstation_id=hdr(1)\n       !write(*,*)\n       !write(*,'(a14,8f14.1)') c_sid,(hdr(i),i=2,8)\n       DO k=1,iret\n         write(*,'(a6,i12,a14,6f17.3,9f17.3,7f17.3)') subset,idate,c_sid,(hdr(i),i=2,6),(obs(i,k),i=1,9),(qcf(i,k),i=1,7)\n       ENDDO\n     enddo sb_report\n     \n   enddo msg_report\n call closbf(unit_in)\n\nend program\n\n\n\n\n\n\nImportant\n\n\n\nThere are excellent resources for learning how to work with BUFR files from which I have taken many things mentioned here:\n\nBUFR/PrepBUFR User’s Guide from the Developmental Testbed Center.\nBUFR Reference Manual from the ECMWF."
+    "text": "An introduction on how to read and write BUFR files\nWorking with BUFR files requires to work with fortran routines. Fortunately there is a library that contains subroutines, functions and other utilities that can be used to read (decode) and write (encode) data in BUFR: NCEPLIBS-bufr. This library is compiled during the compilation of GSI but can also be used independently.\nHere is a simplified example of a routine to decode a bufr file:\nopen(unit_in,file='sample.bufr',action='read',form='unformatted')\ncall openbf(unit_in,'IN',unit_in)\n  \n  msg_report: do while (ireadmg(unit_in,subset,idate) == 0)\n    \n    sb_report: do while (ireadsb(unit_in) == 0)\n\n      call ufbint(unit_in,hdr,3,1 ,iret,hdstr)\n      call ufbint(unit_in,obs,1,10,iret,obstr)\n\n    enddo sb_report\n  \n  enddo msg_report\n\ncall closbf(unit_in)\n\nThe first level of code open and close the file. It uses the openbf() and closebf()functions from the BUFR library.\nThe second level will read each message. Each loop reads in one message until the last message in the file is reached. It uses the ireadmg() function.\nThe third level will read the reports inside each message using the ireadsb().\nAnd finally inside each report, we access the data values using the ufbint() function. In this example we save the header in formation in one array and the observation information in a second array.\n\nGSI includes some example routines as part ad the bufr tools kit. A complete routine to decode a BUFR file can be found here. The routine to encode a BUFR file will have similar characteristics.\nAnd again, BUFR files will be different for different type of observations and you always need the associated mnemonics table.\n\nDecode prepBUFR files\nThis is not different that we’ve seen previously and the BUFR tools folder in the GSI repository has very good examples to use. But I like to have the data in tidy tables, so I’ve modified that code to decode a prepBUFR file into a table where each row is an observation. This is the routine:\nprogram prepbufr_decode_all_df\n!\n! read all observations out from prepbufr. \n! read bufr table from prepbufr file\n! output in a \"data frameish\" type \n!\n implicit none\n\n integer, parameter :: mxmn=35, mxlv=250\n character(80):: hdstr='SID XOB YOB DHR TYP ELV SAID T29'\n character(80):: obstr='POB QOB TOB ZOB UOB VOB PWO CAT PRSS'\n character(80):: qcstr='PQM QQM TQM ZQM WQM NUL PWQ     '\n character(80):: oestr='POE QOE TOE NUL WOE NUL PWE     '\n real(8) :: hdr(mxmn),obs(mxmn,mxlv),qcf(mxmn,mxlv),oer(mxmn,mxlv)\n\n INTEGER        :: ireadmg,ireadsb\n\n character(8)   :: subset\n integer        :: unit_in=10,idate,nmsg,ntb\n\n character(8)   :: c_sid\n real(8)        :: rstation_id\n equivalence(rstation_id,c_sid)\n\n integer        :: i,k,iret\n!\n!\n open(24,file='prepbufr.table')\n open(unit_in,file='prepbufr',form='unformatted',status='old')\n call openbf(unit_in,'IN',unit_in)\n call dxdump(unit_in,24)\n call datelen(10)\n   nmsg=0\n   msg_report: do while (ireadmg(unit_in,subset,idate) == 0)\n     nmsg=nmsg+1\n     ntb = 0\n\n     sb_report: do while (ireadsb(unit_in) == 0)\n       ntb = ntb+1\n       !write(*,*)'New secction: ',ntb,' in msg ',nmsg\n       call ufbint(unit_in,hdr,mxmn,1   ,iret,hdstr)\n       call ufbint(unit_in,obs,mxmn,mxlv,iret,obstr)\n       call ufbint(unit_in,oer,mxmn,mxlv,iret,oestr)\n       call ufbint(unit_in,qcf,mxmn,mxlv,iret,qcstr)\n       rstation_id=hdr(1)\n       !write(*,*)\n       !write(*,'(a14,8f14.1)') c_sid,(hdr(i),i=2,8)\n       DO k=1,iret\n         write(*,'(a6,i12,a14,6f17.3,9f17.3,7f17.3)') subset,idate,c_sid,(hdr(i),i=2,6),(obs(i,k),i=1,9),(qcf(i,k),i=1,7)\n       ENDDO\n     enddo sb_report\n     \n   enddo msg_report\n call closbf(unit_in)\n\nend program\n\n\n\n\n\n\nImportant\n\n\n\nThere are excellent resources for learning how to work with BUFR files from which I have taken many things mentioned here:\n\nBUFR/PrepBUFR User’s Guide from the Developmental Testbed Center.\nBUFR Reference Manual from the ECMWF."
   },
   {
     "objectID": "content/gsi/02-convencionals.html",
     "href": "content/gsi/02-convencionals.html",
     "title": "Assimilating Conventional Observations",
     "section": "",
-    "text": "Conventional observations are assimilated from PREPBUFR files. NCEP ADP Global Upper Air and Surface Weather Observations (PREPBUFR format) are composed of a global set of surface and upper air reports operationally collected by the National Centers for Environmental Prediction (NCEP). These include land surface, marine surface, radiosonde, pibal and aircraft reports from the Global Telecommunications System (GTS), profiler and US radar derived winds, SSM/I oceanic winds and TCW retrievals, and satellite wind data from the National Environmental Satellite Data and Information Service (NESDIS). The reports can include pressure, geopotential height, temperature, dew point temperature, wind direction and speed [@cisl_rda_ds337.0].\nWhile the PREPBUFR includes wind derived from satellite observations, GSI ignores this observations and uses the ones provided by the specific bufr file gdas.t00z.satwnd.tm00.bufr_d.\nPREPBUFR files usually contains observations from a 6 to 12 h window and can be modify using FORTRAN routines provided with the GSI code (see util/bufr_tools in the GSI source code folder). You can also create your own bufr file or add new observation to an existing bufr file (see Working with bufr files).\n\nControlling which observations are assimilated\nThe assimilation of conventional observations is controlled with the convinfo file. Let’s check the global_convinfo.txt file we get as an example:\n! otype   = observation type (a7, t, uv, q, etc.)\n! type    = prepbufr observation type (if available)\n! sub     = prepbufr subtype (not yet available)\n! iuse    = flag if to use/not use / monitor data\n!         = 1  use data\n!         = 0  do not use data\n!         = -1 monitor data\n! twindow = time window (+/- hours)\n! numgrp  = cross validation parameter - number of groups\n! ngroup  = cross validation parameter - group to remove from data use\n! nmiter  = cross validation parameter - external iteration to introduce removed data\n! gross   = gross error parameter - gross error\n! ermax   = gross error parameter - max error\n! ermin   = gross error parameter - min error\n! var_b   = variational quality control parameter -  b parameter\n! var_pg ithin rmesh npred  = variational quality control parameter -  pg parameter\n! pmot: the optione to keep thinned datai as monitored, 0: not to keep, other values: to keep\n! ptime: time interval for thinning, 0, no temporal thinning, other values define time interval (less than 6)\n!otype   type  sub iuse twindow numgrp ngroup nmiter gross ermax ermin var_b    var_pg ithin rmesh  pmesh  npred  pmot  ptime\n tcp      112    0    1     3.0      0      0      0  75.0   5.0   1.0  75.0  0.000000     0    0.     0.      0    0.     0.\n ps       120    0    1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.\n ps       132    0   -1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.\n ps       180    0    1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.\n ps       180    01   1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.\nThe head of the file explains the content of each column but there are a few more things to add:\n\ntype: this is defined by the bufr tables, particular Table 2. It is worth checking this table as includes information about which observations are assimilated in GFS, errors asociated to specific instruments and other details.\ntwindow: while the assimilation window is defined in the gsi namalist, it is possible to control an assimilation window for specific observations. This is useful if, for example the assimilation window is 3 h and you want to assimilate temperature in a 1h window.\n\nIn general you only change the isue column to assimilate or not a type of observation and maybe just maybe the gross, ermax, and ermin parameters if you want to modify the quality control of the observations.\n\n\nObservation errors and quality control\nFor regional assimilation GSI uses an error table located in the errtable file that you’ll find in the ./fix folder under the name prepobs_errtable.global (it is confusing that the table for regional errors in in a file called global). Here is a small example of the content of the file for observations from surface stations.\n181 OBSERVATION TYPE\n  0.11000E+04 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.10500E+04 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.10000E+04 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.95000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.90000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.85000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.80000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.75000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.70000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\nThe meaning of each column is described in the following table:\n\n\n\n\n\n\n\n\n\n\n\n\nColumn #\n1\n2\n3\n4\n5\n6\n\n\n\n\nContent\nPressure\nT\nRH\nUV\nPs\nPw\n\n\nUnit\nhPa\ndegreeC\npercent/10\nm/s\nmb\nkg/m2 (or mm)\n\n\n\nSo column 1 define the pressure level associated to the errors for each variable in columns 2 to 6. In the errtable a 0.10000E+10 is a NA.\nGSI will perform a quality control for each observation. In general terms this involves a gross check and specific controls depending on the type of observation.\nFor the gross check, GSI first calculates a ratio:\n\\[ ratio = (obs - bk)/max(ermin, min(ermax, obserror)) \\] The main error parameters are controlled by the convinfo file. The obserror is the observation error defined in the prepbufr file for each observation as a result to the quality control perform while generating that file.\nIf \\(ration &gt; gross\\) the observation is rejected.\nOther piece of information used during the quality control is the quality control flag that is included in the prepbufr file a part if it quality control process. The possible values for conventional observations are:\n\n\n\n\n\n\n\nqc flag\nmeaning\n\n\n\n\n0-2\n–&gt; Obs is assimilated\n\n\n3\nSuspicious obs –&gt; gross check is more strict\n\n\n4-15\n–&gt; Obs is rejected (for some cases 9 o 15 means that the obs is monitored\n\n\n\nYou can find more details about the quality control flags in Table 7.\nGSI can also perform a thinning for conventional observations. You can activate that option for each type of observation changing ithin = 1 in the convinfo file. There are other important columns, rmesh, pmesh, in the convinfo file to configure conventional data thinning:\n\nithin: 0 = no thinning; 1 = thinning with grid mesh decided by rmesh and pmesh\nrmesh: horizontal thinning grid size in km\npmesh: vertical thinning grid size in mb; if 0, then use background vertical grid\n\nFor each observation GSI will check different things and change the observation error accordingly. The final observation error is recorded in the diag file and then used during the assimilation."
+    "text": "Conventional observations are assimilated from PREPBUFR files. NCEP ADP Global Upper Air and Surface Weather Observations (PREPBUFR format) are composed of a global set of surface and upper air reports operationally collected by the National Centers for Environmental Prediction (NCEP). These include land surface, marine surface, radiosonde, pibal and aircraft reports from the Global Telecommunications System (GTS), profiler and US radar derived winds, SSM/I oceanic winds and TCW retrievals, and satellite wind data from the National Environmental Satellite Data and Information Service (NESDIS). The reports can include pressure, geopotential height, temperature, dew point temperature, wind direction and speed [@cisl_rda_ds337.0].\nWhile the PREPBUFR includes wind derived from satellite observations, GSI ignores this observations and uses the ones provided by the specific bufr file gdas.t00z.satwnd.tm00.bufr_d.\nPREPBUFR files usually contains observations from a 6 to 12 h window and can be modify using FORTRAN routines provided with the GSI code (see util/bufr_tools in the GSI source code folder). You can also create your own bufr file or add new observation to an existing bufr file (see Working with bufr files).\n\nControlling which observations are assimilated\nThe assimilation of conventional observations is controlled with the convinfo file. Let’s check the global_convinfo.txt file we get as an example in the fix folder:\n! otype   = observation type (a7, t, uv, q, etc.)\n! type    = prepbufr observation type (if available)\n! sub     = prepbufr subtype (not yet available)\n! iuse    = flag if to use/not use / monitor data\n!         = 1  use data\n!         = 0  do not use data\n!         = -1 monitor data\n! twindow = time window (+/- hours)\n! numgrp  = cross validation parameter - number of groups\n! ngroup  = cross validation parameter - group to remove from data use\n! nmiter  = cross validation parameter - external iteration to introduce removed data\n! gross   = gross error parameter - gross error\n! ermax   = gross error parameter - max error\n! ermin   = gross error parameter - min error\n! var_b   = variational quality control parameter -  b parameter\n! var_pg ithin rmesh npred  = variational quality control parameter -  pg parameter\n! pmot: the optione to keep thinned datai as monitored, 0: not to keep, other values: to keep\n! ptime: time interval for thinning, 0, no temporal thinning, other values define time interval (less than 6)\n!otype   type  sub iuse twindow numgrp ngroup nmiter gross ermax ermin var_b    var_pg ithin rmesh  pmesh  npred  pmot  ptime\n tcp      112    0    1     3.0      0      0      0  75.0   5.0   1.0  75.0  0.000000     0    0.     0.      0    0.     0.\n ps       120    0    1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.\n ps       132    0   -1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.\n ps       180    0    1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.\n ps       180    01   1     3.0      0      0      0   4.0   3.0   1.0   4.0  0.000300     0    0.     0.      0    0.     0.\nThe head of the file explains the content of each column but there are a few more things to add:\n\ntype: this is defined by the bufr tables, particular Table 2. It is worth checking this table as includes information about which observations are assimilated in GFS, errors associated to specific instruments and other details.\ntwindow: while the assimilation window is defined in the gsi namalist, it is possible to control an assimilation window for specific observations. This is useful if, for example the assimilation window is 3 h and you want to assimilate temperature in a 1h window.\n\nIn general you only change the iuse column to assimilate or not a type of observation and maybe just maybe the gross, ermax, and ermin parameters if you want to modify the quality control of the observations.\n\n\nObservation errors and quality control\nFor regional assimilation GSI uses an error table located in the errtable file that you’ll find in the ./fix folder under the name prepobs_errtable.global (yes, it is confusing that the table for regional errors in in a file called global). Here is a small example of the content of the file for observations from surface stations.\n181 OBSERVATION TYPE\n  0.11000E+04 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.10500E+04 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.10000E+04 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.95000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.90000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.85000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.80000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.75000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\n  0.70000E+03 0.15000E+01 0.20000E+01 0.10000E+10 0.16000E+01 0.10000E+10\nThe meaning of each column is described in the following table:\n\n\n\n\n\n\n\n\n\n\n\n\nColumn #\n1\n2\n3\n4\n5\n6\n\n\n\n\nContent\nPressure\nT\nRH\nUV\nPs\nPw\n\n\nUnit\nhPa\ndegreeC\npercent/10\nm/s\nmb\nkg/m2 (or mm)\n\n\n\nSo column 1 define the pressure level associated to the errors for each variable in columns 2 to 6. In the errtable a 0.10000E+10 is a NA.\nGSI will perform a quality control for each observation. In general terms this involves a gross check and specific controls depending on the type of observation.\nFor the gross check, GSI first calculates a ratio:\n\\[ ratio = (obs - bk)/max(ermin, min(ermax, obserror)) \\] The main error parameters are controlled by the convinfo file. The obserror is the observation error defined in the prepbufr file for each observation plus information in the prepobs_errtable.\nIf \\(ration &gt; gross\\) the observation is rejected.\nOther piece of information used during the quality control is the quality control flag that is included in the prepbufr file a part if it quality control process performed by NCEP. The possible values for conventional observations are:\n\n\n\n\n\n\n\nqc flag\nmeaning\n\n\n\n\n0-2\n–&gt; Obs is assimilated\n\n\n3\nSuspicious obs –&gt; gross check is more strict\n\n\n4-15\n–&gt; Obs is rejected (for some cases 9 o 15 means that the obs is monitored\n\n\n\nYou can find more details about the quality control flags in Table 7.\nGSI can also perform a thinning for conventional observations. You can activate that option for each type of observation changing ithin = 1 in the convinfo file. There are other important columns, rmesh, pmesh, in the convinfo file to configure conventional data thinning:\n\nithin: 0 = no thinning; 1 = thinning with grid mesh decided by rmesh and pmesh\nrmesh: horizontal thinning grid size in km\npmesh: vertical thinning grid size in mb; if 0, then use background vertical grid\n\nFor each observation GSI will check different things and change the observation error accordingly. The final observation error is recorded in the diag file and then used during the assimilation."
   },
   {
     "objectID": "content/gsi/05-tutorial.html",
     "href": "content/gsi/05-tutorial.html",
     "title": "GSI tutorial",
     "section": "",
-    "text": "This tutorial is intended to showcase some of the capabilities of the GSI system. For a more complete set of examples, please visit the official website for GSI: variational methods and [Kalman Filter](https://dtcenter.org/community-code/ensemble-kalman-filter-system-enkf) methods.\nThe tutorial uses the serial Ensemble Square Root Filter (EnSRF) algorithm but could also be used to run the Local Ensemble Kalman Filter (LETKF) algorithm if the GSI system code is compiled using a intel compiler1. It also uses a version of the code that have the capability of assimilating GOES-16 observations."
+    "text": "This tutorial is intended to showcase some of the capabilities of the GSI system. For a more complete set of examples, please visit the official website for GSI: variational methods and Kalman Filter methods.\nThe tutorial uses the serial Ensemble Square Root Filter (EnSRF) algorithm but could also be used to run the Local Ensemble Kalman Filter (LETKF) algorithm if the GSI system code is compiled using a intel compiler1. It also uses a version of the code that have the capability of assimilating GOES-16 observations."
   },
   {
     "objectID": "content/gsi/05-tutorial.html#moving-parts",
     "href": "content/gsi/05-tutorial.html#moving-parts",
     "title": "GSI tutorial",
     "section": "Moving parts",
-    "text": "Moving parts\nThe first component to run the tutorial is the GSI system code that can be found in this repository: github.com/paocorrales/comGSIv3.7_EnKFv1.3. Alternatively, the original code without modifications is available here. The repository includes an example script compile_gsi_yakaira to compile the code. In any case it is important to include the option -DBUILD_WRF=ON to use the ENKF algorithm with WRF.\nThen, clone or download the repository with the scripts, namelists and specific config files from: https://github.com/paocorrales/tutorial_gsi. This repository also includes a bash scripts to download the necessary data to run the tutorial. This data is also available as a Zenodo record.\n\nObservations\nThe observations included in this tutorial are:\nConventional observations: surface and upper air observations (meteorological stations, radiosondes, airplanes, etc.). It also includes wind derived from satellite. The bufr file used here is created from the prepbufr file at 12 UTC of 2018/11/22 and includes also observations from automatic station networks in Argentina and other countries.\n\nFile: cimap.20181122.t12z.01h.prepbufr.nqc\n\nRadiance observations: radiances from polar and geostationary satellites. Observations from polar satellites comes from the Global Data Assimilation System (GDAS) Model: https://www.nco.ncep.noaa.gov/pmb/products/gfs. The GOES-16 observations (ABI sensor) are derived from the public netcdf files published by NOAA.\nFiles:\n\nabig16.20181122.t12z.bufr_d\n1bamua.20181122.t12z.bufr_d\nssmisu.20181122.t12z.bufr_d\n1bhrs4.20181122.t12z.bufr_d\nairsev.20181122.t12z.bufr_d\nmtiasi.20181122.t12z.bufr_d\n1bmhs.20181122.t12z.bufr_d\natms.20181122.t12z.bufr_d\nsatwnd.20181122.t12z.bufr_d\n\n\n\nBackground\nThe background files includes the 10-member ensemble generated using the WRF-ARW numerical model for a regional domain centered in the center and northern Argentina. For more information about the model configuration see https://doi.org/10.1016/j.atmosres.2022.106456\n\nThe 00 subfolder includes a 10-member ensemble and the ensemble mean to run the GSI system using the ENKF version.\nThe 01 to 10 subfolders include the background at the analysis time and files every 10 minutes inside the assimilation window to run the GSI system using the FGAT method"
+    "text": "Moving parts\n\nGSI code\nThe first component to run the tutorial is the GSI system code that can be found in this repository: github.com/paocorrales/comGSIv3.7_EnKFv1.3. Alternatively, the original code without modifications is available here. The repository includes an example script compile_gsi_yakaira to compile the code. In any case it is important to include the option -DBUILD_WRF=ON to use the ENKF algorithm with WRF as model.\nThen, clone or download the repository with the scripts, namelists and specific config files from: https://github.com/paocorrales/tutorial_gsi. This repository also includes a bash scripts to download the necessary data to run the tutorial. This data is also available as a Zenodo record.\n\n\nObservations\nThe observations included in this tutorial are:\nConventional observations: surface and upper air observations (meteorological stations, radiosondes, airplanes, etc.). It also includes wind derived from satellite. The bufr file used here is created from the prepbufr file at 12 UTC of 2018/11/22 and includes also observations from automatic station networks in Argentina and other countries.\n\nFile: cimap.20181122.t12z.01h.prepbufr.nqc\n\nRadiance observations: radiances from polar and geostationary satellites. Observations from polar satellites comes from the Global Data Assimilation System (GDAS) Model: https://www.nco.ncep.noaa.gov/pmb/products/gfs. The GOES-16 observations (ABI sensor) are derived from the public netCDF files published by NOAA.\nFiles:\n\nabig16.20181122.t12z.bufr_d\n1bamua.20181122.t12z.bufr_d\nssmisu.20181122.t12z.bufr_d\n1bhrs4.20181122.t12z.bufr_d\nairsev.20181122.t12z.bufr_d\nmtiasi.20181122.t12z.bufr_d\n1bmhs.20181122.t12z.bufr_d\natms.20181122.t12z.bufr_d\nsatwnd.20181122.t12z.bufr_d\n\n\n\nBackground\nThe background files includes the 10-member ensemble generated using the WRF-ARW numerical model for a regional domain centered in the center and northern Argentina. For more information about the model configuration see https://doi.org/10.1016/j.atmosres.2022.106456\n\nThe 00 subfolder includes a 10-member ensemble and the ensemble mean to run the GSI system using the ENKF version.\nThe 01 to 10 subfolders include the background at the analysis time and files every 10 minutes inside the assimilation window to run the GSI system using the FGAT method"
   },
   {
     "objectID": "content/gsi/05-tutorial.html#structure",
     "href": "content/gsi/05-tutorial.html#structure",
     "title": "GSI tutorial",
     "section": "Structure",
-    "text": "Structure\nBy cloning the tutorial repo and downloading the associated data with the provied script you will end up with the following folder structure.\ntutorial_gsi/\n├── download_data.sh\n├── fix\n│   ├── global_satinfo.txt\n│   ├── satbias_ang\n│   ├── satbias_in\n│   └── satbias_pc_in\n├── GUESS\n│   └── 20181122120000\n│       ├── 00\n│       │   ├── wrfarw.ensmean\n│       │   ├── wrfarw.mem001\n│       │   ├── wrfarw.mem002\n│       │   ├── wrfarw.mem003\n│       │   ├── wrfarw.mem004\n│       │   ├── wrfarw.mem005\n│       │   ├── wrfarw.mem006\n│       │   ├── wrfarw.mem007\n│       │   ├── wrfarw.mem008\n│       │   ├── wrfarw.mem009\n│       │   └── wrfarw.mem010\n│       ├── 01\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 02\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 03\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 04\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 05\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 06\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 07\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 08\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 09\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       └── 10\n│           ├── wrf_inou1\n│           ├── wrf_inou2\n│           ├── wrf_inou3\n│           ├── wrf_inou4\n│           ├── wrf_inou5\n│           ├── wrf_inou6\n│           └── wrf_inou7\n├── namelists\n│   ├── comenkf_namelist.sh\n│   └── comgsi_namelist.sh\n├── OBS\n│   ├── 1bamua.20181122.t12z.bufr_d\n│   ├── 1bhrs4.20181122.t12z.bufr_d\n│   ├── 1bmhs.20181122.t12z.bufr_d\n│   ├── abig16.20181122.t12z.bufr_d\n│   ├── airsev.20181122.t12z.bufr_d\n│   ├── atms.20181122.t12z.bufr_d\n│   ├── cimap.20181122.t12z.01h.prepbufr.nqc\n│   ├── mtiasi.20181122.t12z.bufr_d\n│   ├── satwnd.20181122.t12z.bufr_d\n│   └── ssmisu.20181122.t12z.bufr_d\n├── README.md\n├── run_enkf.sh\n└── run_gsi.sh\nA GSI folder will be created when running the run_gsi.sh script and a ENKF folder will be created when running the run_enkf.sh that performs the analysis."
+    "text": "Structure\nBy cloning the tutorial repo and downloading the associated data with the provided script (download_data.sh) you will end up with the following folder structure.\ntutorial_gsi/\n├── download_data.sh\n├── fix\n│   ├── global_satinfo.txt\n│   ├── satbias_ang\n│   ├── satbias_in\n│   └── satbias_pc_in\n├── GUESS\n│   └── 20181122120000\n│       ├── 00\n│       │   ├── wrfarw.ensmean\n│       │   ├── wrfarw.mem001\n│       │   ├── wrfarw.mem002\n│       │   ├── wrfarw.mem003\n│       │   ├── wrfarw.mem004\n│       │   ├── wrfarw.mem005\n│       │   ├── wrfarw.mem006\n│       │   ├── wrfarw.mem007\n│       │   ├── wrfarw.mem008\n│       │   ├── wrfarw.mem009\n│       │   └── wrfarw.mem010\n│       ├── 01\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 02\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 03\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 04\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 05\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 06\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 07\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 08\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       ├── 09\n│       │   ├── wrf_inou1\n│       │   ├── wrf_inou2\n│       │   ├── wrf_inou3\n│       │   ├── wrf_inou4\n│       │   ├── wrf_inou5\n│       │   ├── wrf_inou6\n│       │   └── wrf_inou7\n│       └── 10\n│           ├── wrf_inou1\n│           ├── wrf_inou2\n│           ├── wrf_inou3\n│           ├── wrf_inou4\n│           ├── wrf_inou5\n│           ├── wrf_inou6\n│           └── wrf_inou7\n├── namelists\n│   ├── comenkf_namelist.sh\n│   └── comgsi_namelist.sh\n├── OBS\n│   ├── 1bamua.20181122.t12z.bufr_d\n│   ├── 1bhrs4.20181122.t12z.bufr_d\n│   ├── 1bmhs.20181122.t12z.bufr_d\n│   ├── abig16.20181122.t12z.bufr_d\n│   ├── airsev.20181122.t12z.bufr_d\n│   ├── atms.20181122.t12z.bufr_d\n│   ├── cimap.20181122.t12z.01h.prepbufr.nqc\n│   ├── mtiasi.20181122.t12z.bufr_d\n│   ├── satwnd.20181122.t12z.bufr_d\n│   └── ssmisu.20181122.t12z.bufr_d\n├── README.md\n├── run_enkf.sh\n└── run_gsi.sh\nA GSI folder will be created when running the run_gsi.sh script and a ENKF folder will be created when running the run_enkf.sh that performs the analysis."
   },
   {
     "objectID": "content/gsi/05-tutorial.html#fgat",
     "href": "content/gsi/05-tutorial.html#fgat",
     "title": "GSI tutorial",
     "section": "Running GSI",
-    "text": "Running GSI\nAs we focus on running GSI with the Kalman Filter method, the first stem is to run GSI as Observation operator. So, the system will compare the observations with the background state and and save that information in diagnostic files.\nThe example used in this tutorial is relatively small, so while you may need a HPC system for real cases, this one can be run in a small server or even a computer with at least 10 processors.\nHere are the ~20 first lines of the script run_gsi.sh:\n#PBS -N TEST-1-GSI \n#PBS -m abe \n#PBS -l walltime=03:00:00 \n#PBS -l nodes=1:ppn=24 \n#PBS -j oe \n\nBASEDIR=/home/paola.corrales/datosmunin3/tutorial_gsi           # Path to the tutorial folder\nGSIDIR=/home/paola.corrales/datosmunin3/comGSIv3.7_EnKFv1.3     # Path to where the GSI/EnKF code is compiled \nFECHA_INI='11:00:00 2018-11-22'                                 # Init time (analysis time - $ANALISIS)\nANALISIS=3600                                                   # Assimilation cycle in seconds\nOBSWIN=1                                                        # Assimilation window in hours\nN_MEMBERS=10                                                    # Ensemble size\nE_WE=200                                                        # West-East grid points\nE_SN=240                                                        # South-North grid points\nE_BT=37                                                         # Vertical levels\n\n\nexport OMP_NUM_THREADS=1\nGSIPROC=10\n\nset-x\nIn principle, you only need to change BASEDIR and GSIDIR variables that are the path to the tutorial folder and the path to where GSI is compiled (the code expects to find a build folder with the executable files.\nSo, with that, you can run the script or send it to a queue.\n\nPossible issues\nThe script assume many things, in particular, where the configuration files, observations and background files are located. If you chance the structure of the folders and files, make sure to do the same in the script.\nThe other very possible issue is machine dependent. GSI creates files with the information of the observations and background called pe\\*something. Those files are later concatenated in diag_&lt;type_of_obs&gt;* files. This process depends on listing all the types of observations with some regex magic:\nlistall=`ls pe* | cut -f2 -d\".\" | awk '{print substr($0, 0, length($0)-2)}' | sort | uniq `\n\n   for type in $listall; do\n      count=`ls pe*${type}_${loop}* | wc -l`\n      if [[ $count -gt 0 ]]; then\n         cat pe*${type}_${loop}* &gt; diag_${type}_${string}.${ANAL_TIME} # For binary diag files\n      fi\n   done\nI had to slightly change that first line every time I changed machines. So, if you don’t see a bunch of diag* files in the GSI folder after running the script this is probably the reason.\n\n\nDid it work?\nIf you get a exit 0 at the end, it probably means that everything went well. However, I recommend you check a few things to make sure everything went really well.\n\nCheck that all the diag* files are there. You will get 1 file per member and ensemble mean for each type of observation. If you don’t see any of these files, check the Issues section. If you are missing the files for 1 type of observation, that probably means that the bufr file with the observations was not read properly or that is missing in the folder. Check if the script is linking the correct file to the GSI folder.\nCheck the statistics for each type of observations. You will find this information in the fit_&lt;obs&gt;.&lt;date&gt; files. Each one may have different information or structure depending on the type of observation, but make sure to check the number of observations read and keep by the system. This information is also included in the stdout file, you can sear READ_* to find the section in the file.\n\nIf you got an error number instead and, if you are lucky, the error code may be described in gsimain.f90."
+    "text": "Running GSI\nAs we focus on running GSI with the Kalman Filter method, the first step is to run GSI as Observation operator. So, the system will compare the observations with the background state and and save that information in diagnostic files.\nThe example used in this tutorial is relatively small, so while you may need a HPC system for real cases, this one can be run in a small server or even a computer with at least 10 processors.\nHere are the ~20 first lines of the script run_gsi.sh:\n#PBS -N TEST-1-GSI \n#PBS -m abe \n#PBS -l walltime=03:00:00 \n#PBS -l nodes=1:ppn=24 \n#PBS -j oe \n\nBASEDIR=/home/paola.corrales/datosmunin3/tutorial_gsi           # Path to the tutorial folder\nGSIDIR=/home/paola.corrales/datosmunin3/comGSIv3.7_EnKFv1.3     # Path to where the GSI/EnKF code is compiled \nFECHA_INI='11:00:00 2018-11-22'                                 # Init time (analysis time - $ANALISIS)\nANALISIS=3600                                                   # Assimilation cycle in seconds\nOBSWIN=1                                                        # Assimilation window in hours\nN_MEMBERS=10                                                    # Ensemble size\nE_WE=200                                                        # West-East grid points\nE_SN=240                                                        # South-North grid points\nE_BT=37                                                         # Vertical levels\n\n\nexport OMP_NUM_THREADS=1\nGSIPROC=10\n\nset-x\nIn principle, you only need to change BASEDIR and GSIDIR variables that are the path to the tutorial folder and the path to where GSI is compiled (the code expects to find a build folder with the executable files inside GSIDIR).\nSo, with that, you can run the script or send it to a queue.\n\nPossible issues\nThe script assume many things, in particular, where the configuration files, observations and background files are located. If you chance the structure of the folders and files, make sure to do the same in the script.\nThe other very possible issue is machine dependent. GSI creates files with the information of the observations and background called pe\\*something. Those files are later concatenated in diag_&lt;type_of_obs&gt;* files. This process depends on listing all the types of observations with some regex magic:\nlistall=`ls pe* | cut -f2 -d\".\" | awk '{print substr($0, 0, length($0)-2)}' | sort | uniq `\n\n   for type in $listall; do\n      count=`ls pe*${type}_${loop}* | wc -l`\n      if [[ $count -gt 0 ]]; then\n         cat pe*${type}_${loop}* &gt; diag_${type}_${string}.${ANAL_TIME} # For binary diag files\n      fi\n   done\nI had to slightly change that first line every time I changed machines. So, if you don’t see a bunch of diag* files in the GSI folder after running the script this is probably the reason.\n\n\nDid it work?\nIf you get a exit 0 at the end, it probably means that everything went well. However, I recommend you check a few things to make sure everything went really well.\n\nCheck that all the diag* files are there. You will get 1 file per member and ensemble mean for each type of observation. If you don’t see any of these files, check the Issues section. If you are missing the files for 1 type of observation, that probably means that the bufr file with the observations was not read properly or that is missing in the folder. Check if the script is linking the correct file to the GSI folder.\nCheck the statistics for each type of observations. You will find this information in the fit_&lt;obs&gt;.&lt;date&gt; files. Each one may have different information or structure depending on the type of observation, but make sure to check the number of observations read and keep by the system. This information is also included in the stdout file, you can search for READ_* to find the section in the file.\n\nIf you got an error number instead and, if you are lucky, the error code may be described in gsimain.f90."
   },
   {
     "objectID": "content/gsi/05-tutorial.html#running-enkf",
@@ -242,7 +242,7 @@
     "href": "content/gsi/05-tutorial.html#running-gsi-using-the-fgat-method",
     "title": "GSI tutorial",
     "section": "Running GSI using the FGAT method",
-    "text": "Running GSI using the FGAT method\nThe tutorial is configured to use the FGAT (First Guess at Appropriate Time) methods, this means that will GSI attempt to read multiple time level backgrounds a show in the following diagram.\n\n\n\nFGAT method\n\n\nThere is no option in the namelist or configuration files to use the FGAT method. To “activate” this option GSI needs to find the appropiate files in appropriate folder. In this example we have 7 files in total for each member, 1 background file at the assimilation time plus 3 files every 10 minutes before and after the assimilation time.\nSo, GSI will expect to find files called wrf_inou1 to wrf_inou7. The fonder structure looks like this:\nGUESS/\n└── 20181122120000\n    ├── 00\n    │   ├── wrfarw.ensmean\n    │   ├── wrfarw.mem001\n    │   ├── wrfarw.mem002\n    │   ├── wrfarw.mem003\n    │   ├── wrfarw.mem004\n    │   ├── wrfarw.mem005\n    │   ├── wrfarw.mem006\n    │   ├── wrfarw.mem007\n    │   ├── wrfarw.mem008\n    │   ├── wrfarw.mem009\n    │   └── wrfarw.mem010\n    ├── 01\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 02\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 03\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 04\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 05\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 06\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 07\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 08\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 09\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    └── 10\n        ├── wrf_inou1\n        ├── wrf_inou2\n        ├── wrf_inou3\n        ├── wrf_inou4\n        ├── wrf_inou5\n        ├── wrf_inou6\n        └── wrf_inou7\nThe files in folders 01 to 10 are the ones used during the assimilation. The files in fonder 00 where used to calculate the ensemble mean and can be also used to run GSI without the FGAT option. For that it is necessary to uncomment line 102 in the run_gsi.sh script:\n# BK_FILE_mem=${BK_ROOT}/wrfarw.mem\nand change lines 600 and 601 from:\ncp ${BK_ROOT}/${ensmemid}/wrf_inou* .\nBK_FILE_ANA=wrf_inou4\nto:\ncp ${BK_ROOT}/00/wrfarw_mem0${ensmemid}.\nBK_FILE_ANA=${BK_FILE}\nThat way, GSI will ignore the other folder and only use 1 background file for each member.\nTo check if GSI is doing what’s suppose to, we need to check the stdout file created during the observation operator step.\nCONVERT_NETCDF_MASS:  problem with flnm1 = wrf_inou1, Status =        -1021\nMeans that GSI did not find all the background files and only used the one at the analysis time.\nInstead if you see something this:\nconvert wrf_inou1 to sigf01\n  iy,m,d,h,m,s=        2018          11          22          11          30           0\n  dh1  =            1\n rmse_var = SMOIS\n ndim1 =            3\n ordering = XYZ\n staggering =  N/A\n start_index =            1           1           1           0\n end_index =          199         239           4           0\nYou’ll know that GSI is using the FGAT method. The example here shows that GSI found the wrf_inout1 file that is renaming to sig01 and then, information related to the time and domain characteristics. This will be repeated for each background file. In this case the first file corresponds to th 11:30 UTC of November 2018 and after that there is 1 file every 10 minutes.\nThis period between background files (10 minutes) is defined by the user when saving the background files. Again there is no configuration option to do this. GSI relies on finding the files in the especified folder.\n\n\n\n\n\n\n\nImportant\n\n\n\nThe run_gsi.sh and run_enkf.sh scripts mentioned in this tutorial are derived from the example scripts provided with the Community GSIV3.7 Online Tutorial."
+    "text": "Running GSI using the FGAT method\nThe tutorial is configured to use the FGAT (First Guess at Appropriate Time) methods, this means that will GSI attempt to read multiple time level backgrounds as show in the following diagram.\n\n\n\nFGAT method\n\n\nThere is no option in the namelist or configuration files to use the FGAT method. To “activate” this option GSI needs to find the appropriate files in appropriate folder. In this example we have 7 files in total for each member, 1 background file at the assimilation time plus 3 files every 10 minutes before and after the assimilation time.\nSo, GSI will expect to find files called wrf_inou1 to wrf_inou7. The fonder structure looks like this:\nGUESS/\n└── 20181122120000\n    ├── 00\n    │   ├── wrfarw.ensmean\n    │   ├── wrfarw.mem001\n    │   ├── wrfarw.mem002\n    │   ├── wrfarw.mem003\n    │   ├── wrfarw.mem004\n    │   ├── wrfarw.mem005\n    │   ├── wrfarw.mem006\n    │   ├── wrfarw.mem007\n    │   ├── wrfarw.mem008\n    │   ├── wrfarw.mem009\n    │   └── wrfarw.mem010\n    ├── 01\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 02\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 03\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 04\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 05\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 06\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 07\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 08\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    ├── 09\n    │   ├── wrf_inou1\n    │   ├── wrf_inou2\n    │   ├── wrf_inou3\n    │   ├── wrf_inou4\n    │   ├── wrf_inou5\n    │   ├── wrf_inou6\n    │   └── wrf_inou7\n    └── 10\n        ├── wrf_inou1\n        ├── wrf_inou2\n        ├── wrf_inou3\n        ├── wrf_inou4\n        ├── wrf_inou5\n        ├── wrf_inou6\n        └── wrf_inou7\nThe files in folders 01 to 10 are the ones used during the assimilation. The files in fonder 00 where used to calculate the ensemble mean and can be also used to run GSI without the FGAT option. For that it is necessary to uncomment line 102 in the run_gsi.sh script:\n# BK_FILE_mem=${BK_ROOT}/wrfarw.mem\nand change lines 600 and 601 from:\ncp ${BK_ROOT}/${ensmemid}/wrf_inou* .\nBK_FILE_ANA=wrf_inou4\nto:\ncp ${BK_ROOT}/00/wrfarw_mem0${ensmemid}.\nBK_FILE_ANA=${BK_FILE}\nThat way, GSI will ignore the other folder and only use 1 background file for each member.\nTo check if GSI is doing what’s suppose to, we need to check the stdout file created during the observation operator step.\nCONVERT_NETCDF_MASS:  problem with flnm1 = wrf_inou1, Status =        -1021\nMeans that GSI did not find all the background files and only used the one at the analysis time.\nInstead if you see something this:\nconvert wrf_inou1 to sigf01\n  iy,m,d,h,m,s=        2018          11          22          11          30           0\n  dh1  =            1\n rmse_var = SMOIS\n ndim1 =            3\n ordering = XYZ\n staggering =  N/A\n start_index =            1           1           1           0\n end_index =          199         239           4           0\nYou’ll know that GSI is using the FGAT method. The example here shows that GSI found the wrf_inout1 file that is renaming to sig01 and then, information related to the time and domain characteristics. This will be repeated for each background file. In this case the first file corresponds to th 11:30 UTC of November 2018 and after that there is 1 file every 10 minutes.\nThis period between background files (10 minutes) is defined by the user when saving the background files. Again there is no configuration option to do this. GSI relies on finding the files in the specified folder.\n\n\n\n\n\n\n\nImportant\n\n\n\nThe run_gsi.sh and run_enkf.sh scripts mentioned in this tutorial are derived from the example scripts provided with the Community GSIV3.7 Online Tutorial."
   },
   {
     "objectID": "content/gsi/05-tutorial.html#footnotes",
@@ -256,34 +256,34 @@
     "href": "contribute.html",
     "title": "How to contribute",
     "section": "",
-    "text": "This outlines how to propose a change to DA-documentation."
+    "text": "This outlines how to propose a change to this website."
   },
   {
     "objectID": "contribute.html#fixing-typos",
     "href": "contribute.html#fixing-typos",
     "title": "How to contribute",
     "section": "Fixing typos",
-    "text": "Fixing typos\nYou can fix typos, spelling mistakes, or grammatical errors in the documentation directly using the GitHub web interface, as long as the changes are made in the source file. This will automatically open a pull request"
+    "text": "Fixing typos\nYou can fix typos, spelling mistakes, or grammatical errors in the documentation directly using the GitHub web interface, as long as the changes are made in the source file. This will automatically open a pull request in the repo."
   },
   {
     "objectID": "contribute.html#bigger-changes",
     "href": "contribute.html#bigger-changes",
     "title": "How to contribute",
     "section": "Bigger changes",
-    "text": "Bigger changes\nIf you want to make a bigger change, it’s a good idea to first file an issue to start a conversation."
+    "text": "Bigger changes\nIf you want to make a bigger change, it’s a good idea to first open an issue to start a conversation."
   },
   {
     "objectID": "contribute.html#pull-request-process",
     "href": "contribute.html#pull-request-process",
     "title": "How to contribute",
     "section": "Pull request process",
-    "text": "Pull request process\nTo open a pull request you’ll need to fork the repository. This website is builded with quarto, make sure you have it installed if you want to build the website locally to test the chances you are proposing."
+    "text": "Pull request process\nTo open a pull request you’ll need to fork the repository. This website is built with quarto, make sure you have it installed if you want to build the website locally to test the chances you are proposing."
   },
   {
     "objectID": "contribute.html#acknowledgements",
     "href": "contribute.html#acknowledgements",
     "title": "How to contribute",
     "section": "Acknowledgements",
-    "text": "Acknowledgements\nIf you contribute to this guide, I’d like to publicly acknowledge you work. Please indicate in you PR if you want to be add to the Contributors page."
+    "text": "Acknowledgements\nIf you contribute to this guide, I’d like to publicly acknowledge your work. Please indicate in you PR if you want to be add to the Contributors page."
   }
 ]
\ No newline at end of file
diff --git a/sitemap.xml b/sitemap.xml
index d98800c..9fd2fc1 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,54 +2,54 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/license.html</loc>
-    <lastmod>2024-02-14T00:04:35.632Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.279Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/content/gsi/03-radiances.html</loc>
-    <lastmod>2024-02-14T00:04:35.624Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.267Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/content/gsi/01-gsi.html</loc>
-    <lastmod>2024-02-14T00:04:35.624Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.267Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/content/gsi/04-diagfiles.html</loc>
-    <lastmod>2024-02-14T00:04:35.624Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.267Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/content/observations/03-rad-bufr.html</loc>
-    <lastmod>2024-02-14T00:04:35.628Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.271Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/index.html</loc>
-    <lastmod>2024-02-14T00:04:35.632Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.275Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/about.html</loc>
-    <lastmod>2024-02-14T00:04:35.624Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.267Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/contributors.html</loc>
-    <lastmod>2024-02-14T00:04:35.632Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.275Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/content/observations/02-conv-bufr.html</loc>
-    <lastmod>2024-02-14T00:04:35.628Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.271Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/content/observations/01-bufr.html</loc>
-    <lastmod>2024-02-14T00:04:35.628Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.271Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/content/gsi/02-convencionals.html</loc>
-    <lastmod>2024-02-14T00:04:35.624Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.267Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/content/gsi/05-tutorial.html</loc>
-    <lastmod>2024-02-14T00:04:35.624Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.267Z</lastmod>
   </url>
   <url>
     <loc>https://paocorrales.github.io/DA-documentation/contribute.html</loc>
-    <lastmod>2024-02-14T00:04:35.632Z</lastmod>
+    <lastmod>2024-02-14T16:08:30.275Z</lastmod>
   </url>
 </urlset>