Pages

Monday, December 24, 2018

Research Note #19 - Installing prep_chem_sources Utility for WRF-Chem

This has been probably one of the trickiest installations I've ever experienced, thanks to the lack of necessary library, limited references and bug in the source code. 

In order to install (or rather, compile) prep_chem_sources tool (I'll call it PCS from now on), HDF5, NetCDF and ZLIB libraries are necessary. Since NetCDF and ZLIB have been already available from previous WRF installation, one should only care about HDF5. Be advised though, HDF5 library of Oakforest super computer module was not compatible with the installation script. Thus, newly fresh HDF5 library is necessary (latest version might be compatible, thus keep checking updates of the super computer).

1. HDF5 Library Installation
Download the latest version from HDF group website. For this case, the version used is HDF5-1.10.4. Extract the file in a directory and execute installation script. Since PCS needs ZLIB and Fortran library, do not forget to mention them during the configuration.

$ ./configure --prefix=/work/gi55/c24223/libs/hdf5 --enable-fortran --enable-cxx --with-zlib=/work/gi55/c24223/libs/grib2
$ ./make
$ ./make check
$ ./make install

Make sure no errors occurred during the installation. After installing HDF5, put its path and LD_LIBRARY_PATH in the .bash_profile and re-load the file.

export HDF5=$PACSLIB/hdf5
export PATH=$HDF5/bin:$PATH

export LD_LIBRARY_PATH= ... :/work/gi55/c24223/libs/hdf5/lib

2. Download PCS tool
Download the tool from this ftp site directory: ftp://aftp.fsl.noaa.gov/divisions/taq/global_emissions

By the time this note was written, the latest version of PCS tool is ver. 1.5. Extract the tools inside any desired directory. Once extracted, there will a directory PREP-CHEM-SRC-1.5 with several sub-directories such as: /bin, /src, /extra etc.

3. Edit  convert_edgar_to_RELACS_REAC.f90 Script
This step should be done, otherwise PCS installation will fail with following messages:

convert_edgar_to_RELACS_REAC.f90(17): error #6405: The same named entity from different modules and/or program units cannot be referenced. [CO]
,CO &
-----------------------------^
convert_edgar_to_RELACS_REAC.f90(20): error #6405: The same named entity from different modules and/or program units cannot be referenced. [CH4]
,CH4 &
-----------------------------^
convert_edgar_to_RELACS_REAC.f90(21): error #6405: The same named entity from different modules and/or program units cannot be referenced. [SO2]
,SO2 &
-----------------------------^
compilation aborted for convert_edgar_to_RELACS_REAC.f90 (code 1)

make: *** [convert_edgar_to_RELACS_REAC.o] Error 1

The cause of this error is ironically simple: the absence of remark symbol ('!') in front of the 9th line of script convert_edgar_to_RELACS_REAC.f90 in the /src sub-directory:

8 subroutine convert_edgar_to_relacs_reac(isp,iespc,ident,spc_name_dummy)  !kml
9 use chem1_list
10 !use chem1_list, only : alke, bio,ora2,aro,ket,alka,ald

Thus, edit the script by adding '!' symbol in front of the said line using vi or other text editor.

4. Edit include.mk.intel.wrf Option Script and Compile PCS
This step is briefly explained on emission guide of WRF-Chem, however no further explanation about the script options available since it will strictly depend on the machine/system architecture. Anyway, one useful hint is: use the same options with WRF-Chem installation used, which are stored inside file configure.wrf inside /WRFV3 sub-directory.

Go to /bin/build sub-directory of PCS, and edit include.mk.intel.wrf option script (since the compiler used is intel compiler). Change these settings as follows:

update 2019/01/31:
Changed F_OPTS because the "longer" version caused crash during execution of utility for GOCART background data.

NETCDF=/work/gi55/c24223/libs/netcdf
HDF5=/work/gi55/c24223/libs/hdf5
HDF5_LIB=-L$(HDF5)/lib -lhdf5hl_fortran -lhdf5_fortran -lhdf5_hl -lhdf5 -L/work/gi55/c24223/libs/grib2/lib -lz -ldl

F_COMP=mpif90 -f90=ifort
C_COMP=mpicc -cc=icc -DMPI2_SUPPORT
LOADER=$(F_COMP)
C_LOADER=$(C_COMP) -DFSEEKO64_OK
F_OPTS=-fpp -D$(CHEM) -O3 -convert big_endian
C_OPTS= -O2

LOADER_OPTS= -O2

Save the script and compile PCS (for GOCART chem option):

$ make OPT=intel.wrf CHEM=RADM_WRF_FIM

If everything's going well, an executable prep_chem_sources_RADM_WRF_FIM_.exe will be created in /bin sub-directory. Check with ldd command to make sure there are no missing shared library links of the executable.

$ ldd prep_chem_sources_RADM_WRF_FIM_.exe
        linux-vdso.so.1 =>  (0x00007ffc35bbe000)
        libnetcdff.so.6 => /work/gi55/c24223/libs/netcdf/lib/libnetcdff.so.6 (0x00007ff8b2825000)
        libnetcdf.so.11 => /work/gi55/c24223/libs/netcdf/lib/libnetcdf.so.11 (0x00007ff8b23cf000)
        libhdf5hl_fortran.so.100 => /work/gi55/c24223/libs/hdf5/lib/libhdf5hl_fortran.so.100 (0x00007ff8b21a8000)
        libhdf5_fortran.so.100 => /work/gi55/c24223/libs/hdf5/lib/libhdf5_fortran.so.100 (0x00007ff8b1f45000)
        libhdf5_hl.so.100 => /work/gi55/c24223/libs/hdf5/lib/libhdf5_hl.so.100 (0x00007ff8b1d1c000)
        libhdf5.so.103 => /work/gi55/c24223/libs/hdf5/lib/libhdf5.so.103 (0x00007ff8b1679000)
        libz.so.1 => /work/gi55/c24223/libs/grib2/lib/libz.so.1 (0x00007ff8b145a000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007ff8b1237000)
        libmpifort.so.12 => /home/opt/local/cores/intel/impi/2018.1.163/intel64/lib/libmpifort.so.12 (0x00007ff8b0e8d000)
        libmpi.so.12 => /home/opt/local/cores/intel/impi/2018.1.163/intel64/lib/libmpi.so.12 (0x00007ff8b0208000)
        librt.so.1 => /lib64/librt.so.1 (0x00007ff8b0000000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff8afde3000)
        libm.so.6 => /lib64/libm.so.6 (0x00007ff8afae1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff8af71e000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff8af507000)
        libhdf5_hl.so.10 => /work/opt/local/apps/intel/2017.1.132/hdf5/1.8.17/lib/libhdf5_hl.so.10 (0x00007ff8af2db000)
        libhdf5.so.10 => /work/opt/local/apps/intel/2017.1.132/hdf5/1.8.17/lib/libhdf5.so.10 (0x00007ff8aebb3000)
        libifport.so.5 => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/libifport.so.5 (0x00007ff8ae984000)
        libifcoremt.so.5 => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/libifcoremt.so.5 (0x00007ff8ae5f0000)
        libimf.so => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/libimf.so (0x00007ff8ae061000)
        libsvml.so => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/libsvml.so (0x00007ff8ac9ae000)
        libintlc.so.5 => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/libintlc.so.5 (0x00007ff8ac740000)
        libirng.so => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/libirng.so (0x00007ff8ac3cc000)
        /lib64/ld-linux-x86-64.so.2 (0x00005572db0f7000)
   

Tuesday, December 18, 2018

Research Note #18 - Installing WRF-Chem with Kinetic Pre-Processor (KPP)

The installation process is basically similar with typical WRF-Chem, with the additional steps to set KPP environment variables and flex library installation. To make it simple, these are the steps to install WRF-Chem with KPP. It assumes that 'yacc' (yet another compiler) has been installed into the system.

1. Install Flex Library
Flex library could be free-downloaded easily from many sources on internet. For this case, GNU flex used could be obtained from this link.

After downloading, extract the files into any desired directory. Next, run configuration script, and compile as usual. Simple as that.

$ ./configure --prefix=$PACSLIB/flex
$ make
$ make check
$ make install

Make sure that file libfl.a exists in $PACSLIB/flex/lib directory after compilation.
More detailed steps could be found here.

2. Setting the Environment Variables
This step is available on WRF-Chem manual. Just set the environment variables on bash shell for these values:

$ export WRF_KPP=1
$ export YACC="/usr/bin/yacc -d"
$ export FLEX_LIB_DIR=$PACSLIB/flex/lib

The most important thing, add the path of flex shared library (libfl.so.2) to the LD_LIBRARY_PATH of .bash_profile, otherwise, the installation of WRF-Chem will fail. For example:

$ export LD_LIBRARY_PATH=/home/opt/local/cores/intel/impi/2018.1.163/intel64/lib:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/mkl/lib/intel64:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64_lin:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/mpi/intel64/lib:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/mpi/mic/lib:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/ipp/lib/intel64:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/mkl/lib/intel64:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/tbb/lib/intel64/gcc4.7:/home/opt/local/cores/intel/debugger_2018/libipt/intel64/lib:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/daal/lib/intel64_lin:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/daal/../tbb/lib/intel64_lin/gcc4.7:/home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/daal/../compiler/lib/intel64_lin:/work/gi55/c24223/libs/grib2/lib:/work/gi55/c24223/libs/netcdf/lib:/work/gi55/c24223/libs/flex/lib

Re-run the bash_profile script:

$ . ~/.bash_profile

3. Install the WRF-Chem
Finally, install WRF-Chem as described on this previous post. If the bash_profile file has already listed netcdf libraries and impi libraries, just go straight to step #3.

The compilation of WRF-Chem's executables with KPP is somehow longer than typical model. New updates and details will be added after WPS compilation. 



Wednesday, November 28, 2018

Research Note #17 - WRF-Chem Simulation with ECMWF ERA-Interim Data

Running WRF-Chem with ERA-Interim data is basically similar with GFS data. The main difference is the pre-processing steps. While GFS (FNL or forecast) dataset contains everything the user needs for the pre-processing, ECMWF (ERA-Interim, Era5 etc) dataset requires more efforts from user to determine parameters included in the data before downloading and processing it. It may seems bothersome and complicated, but determination of parameters is really important to understand how WRF model works.

The key point here is WRF's Vtable file, which contains all parameter needed for simulation. Once you understand the contents of the file (in accordance with the type of input data), you can basically use WRF with many kinds of input dataset.

To make long story short, here are steps for running WRF-Chem with ERA-Interim dataset:

1. Downloading Data
  • Go to ECMWF website, and log-in to it. An account is required for downloading data, thus if you don't have one, just register a new account. It's free.
  • Once you logged in, browse into Forecast > Datasets > Archived Datasets > Reanalysis Datasets, and finally, select Download on ERA-Interim section. You will be directed to ERA-Interim, Daily data page.
  • Now, the most important thing, WRF needs two kinds of level type for the data: surface and levels. Aside from surface level, there are at least two kinds of level type could be used for WRF: pressure levels and model levels. Which level type you use will depend on Vtable you use for WRF (wrf directory/ungrib/Variable_Tables). For this example, I use Vtable.ERA-interim.ml, which means I will use model levels type dataset. Another important thing, aside from daily data, you will need Invariant data for the data field. This data is static and not time-varied as daily data, hence you only need to download it once.
  • For the surface level data, on Type of Level section, select Surface, and put a tick on the month and year section. Regardless the data period of your interest, you have to download the data for at least one whole month. Next, select the time of the data. If you want to use 6-hourly boundary condition data, put check to all time box. For the step (model cycle), choose 0. Finally, you should choose 18 parameters of the surface level data (which are listed in WRF Vtable file): 2m temperature, 10m U wind component, 10m V wind component, mean sea level pressure, sea surface temperature, sea ice area fraction, skin temperature, snow density, snow depth, surface pressure, soil temperature levels (1,2,3 and 4) and finally, volumetric soil water layers (1,2,3 and 4). Click Retrieve GRIB. The website will summarize your request and if you think it's correct, click Retrieve now, and wait until the download link appears. Depending on the size of the data you requested, this process may take up to 1 minute to hours to complete. All those parameters will be downloaded as single file. Give it suitable name e.g. era-int-201711-sfc.grib.
  • For the model levels data, on Type of Level section, select Model levels. The steps are almost similar with surface level data download. This time you only need to select the month, year, time and 5 parameters on all levels: specific humidity, temperature, U component of wind, V component of wind and geopotential. Click Retrieve GRIB, and the rest will be same as surface level data download procedure. Anyway, since geopotential data is only available for one level, you could download it separately from the others. For example, the downloaded data will be named era-int-201711-geo.grib (for geopotential) and era-int-201711-mod.grib (for the other parameters). Therefore, there will be two model levels data files.  
  • Finally, don't forget to download the Invariant data. On ERA Interim Fields section, select Invariant, and put check on Land-Sea Mask, then click Retrieve GRIB and so on. Name it into era-int-invariant.grib.
  • In the end, based on this example, there are four files you should have from the website: era-int-201711-sfc.grib (surface levels), era-int-201711-geo.grib (model levels geopotential), era-int-201711-mod.grib (model levels other than geopotential) and era-int-invariant.grib (land-sea mask invariant).

2. WRF Pre-processing

  • Make sure you have already set the model domain (by geogrid.exe) and set the dynamic link of Vtable to Vtable.ERA-interim.ml file.
  • Link all ERA-Interim data downloaded by link_grib.csh script, and execute ungrib.exe. Wait until the process finished.
  • The next step after ungrib is very important. ECMWF model levels data uses sigma levels, while WRF requires pressure levels, thus you need to calculate the pressure level of the corresponding sigma level using utility calc_ecmwf_p.exe (WPS/util/calc_ecmwf_p.exe). You have to do this before executing metgrid.exe. Failing to do so may result on model crashes or unrealistic simulation results (as I previously experienced). Assuming this is the first time you use ERA-Interim data, open namelist.wps and add 'PRES' to the list of prefixes in the fg_name namelist variable.
          &metgrid
          fg_name = 'FILE', 'PRES',
  • Make a dynamic link of the calc_ecmwf_p.exe to the current working WPS directory and make a text file with this following template, then save and name it: 'ecmwf_coeffs':

    0         0.000000    0.00000000
    1        20.000000    0.00000000
    2        38.425343    0.00000000
    3        63.647804    0.00000000
    4        95.636963    0.00000000
    5       134.483307    0.00000000
    6       180.584351    0.00000000
    7       234.779053    0.00000000
    8       298.495789    0.00000000
    9       373.971924    0.00000000
   10       464.618134    0.00000000
   11       575.651001    0.00000000
   12       713.218079    0.00000000
   13       883.660522    0.00000000
   14      1094.834717    0.00000000
   15      1356.474609    0.00000000
   16      1680.640259    0.00000000
   17      2082.273926    0.00000000
   18      2579.888672    0.00000000
   19      3196.421631    0.00000000
   20      3960.291504    0.00000000
   21      4906.708496    0.00000000
   22      6018.019531    0.00000000
   23      7306.631348    0.00000000
   24      8765.053711    0.00007582
   25     10376.126953    0.00046139
   26     12077.446289    0.00181516
   27     13775.325195    0.00508112
   28     15379.805664    0.01114291
   29     16819.474609    0.02067788
   30     18045.183594    0.03412116
   31     19027.695313    0.05169041
   32     19755.109375    0.07353383
   33     20222.205078    0.09967469
   34     20429.863281    0.13002251
   35     20384.480469    0.16438432
   36     20097.402344    0.20247594
   37     19584.330078    0.24393314
   38     18864.750000    0.28832296
   39     17961.357422    0.33515489
   40     16899.468750    0.38389215
   41     15706.447266    0.43396294
   42     14411.124023    0.48477158
   43     13043.218750    0.53570992
   44     11632.758789    0.58616841
   45     10209.500977    0.63554746
   46      8802.356445    0.68326861
   47      7438.803223    0.72878581
   48      6144.314941    0.77159661
   49      4941.778320    0.81125343
   50      3850.913330    0.84737492
   51      2887.696533    0.87965691
   52      2063.779785    0.90788388
   53      1385.912598    0.93194032
   54       855.361755    0.95182151
   55       467.333588    0.96764523
   56       210.393890    0.97966272
   57        65.889244    0.98827010
   58         7.367743    0.99401945
   59         0.000000    0.99763012
   60         0.000000    1.00000000
  • Execute the utility and wait until it completes calculating the pressure levels. This results new files with prefix 'PRES' in current directory. Once finished, you can execute metgrid.exe. This will complete the pre-processing steps.
3. Running WRF
  • Open namelist.input in WRF's run directory, and pay attention to these following variables, since they are closely related to ECMWF data, e.g. number of metgrid pressure levels. Modify the values as follows:
&domains  
num_metgrid_levels = 61 [default 32]

&physics
surface_input_sources= 1 [default 3]
  • Execute real.exe and finally, wrf.exe to run the model.  
That's it. This post will be updated once something new occurred in the future.

Friday, November 16, 2018

Gunpa #39 - HGUC Sinanju Stein (Narrative Version)


I've never been a big fan of the red Sinanju from Unicorn series. While it's really cool, I still prefer the 'fat' Sazabi than Sinanju. In my humble opinion, Sinanju is an over-designed mobile suit and lacks the war robot theme which is one of the aspects I like the most about gundam and real-robot genre. And then, comes the Sinanju Stein, which is basically the Sinanju, before 'stolen' and modified by Neo Zeon for Full Frontal, the second coming of Char. In almost every aspect, Sinanju Stein is very same with Sinanju. The difference lies on the aesthetics since the mobile suit was built by Anaheim Electronics, the main MS supplier of Earth Federation. Sinanju Stein appearance is just like a mixed of Nu Gundam and Sazabi. It has gundam face and eyes, sharp-angled design as typical EFSF mobile suits, while inheriting the body shape of Sazabi and proportion as well as color scheme of Nu Gundam. Anyway, what I like the most about Sinanju Stein is it looks much more like a war robot than a super robot as red Sinanju. Therefore, when Bandai announced that they will release Sinanju Stein in HGUC line, I was so hype for it.


I got the kit from コジマ (Kojima), one of the retail stores which has the most gunpla collection in the city, with the price of 1980 Yen (the original price is 2600 Yen). It has 11 runners, with one comes runner from HGUC Sinanju (D runner), and one comes from HGUC Neo Zeong (F runner). One may think it's just a retooling from Sinanju, but in fact, it mostly uses new design, in particular with the body armor parts.


After completed the assembly, one could easily tell that this kit actually a miniature version of MG Sinanju Stein. Aside from inner frame and several gimmicks, it almost looks identical with the MG version, especially the panel lines. If only it comes with proper decals, this HG kit will look exactly similar with its MG counterpart. The main differences between the original Stein and Narrative version are (of course) the Neo Zeon emblems on the chest and sleeves, grayish color scheme instead of white, longer fuel tanks and slightly different beam rifle. Cool thing of this kit is, it provides option parts for making shorter fuel tanks and extra parts (with different color) for the leg thrusters, which makes me quite sure that Bandai will likely released the original Sinanju Stein, probably as P-Bandai. Also, the fact that Stein's beam rifle is slightly retooled of Sinanju's is a big plus. At least the builder has option to choose between Stein or Sinanju beam rifle for customization.

Stein and Sazabi (with action base)
Now, lets talk about articulation. Stein narrative version has quite unique articulation on the shoulder parts which enables the arms to stretch out, to the front, back or upwards. Also, the elbow connection is quite stiff, hence holding such a huge beam rifle is not a problem at all. The legs/knee could bend quite far inside, which is really good. The hands, feet and (unfortunately) waist use ball joint connection which is typical for a HG kit. The leg and backpack thursters also have articulation gimmicks. All I can say is this kit has really good articulation and it's easy to make cool poses with it (just look at the pictures).


For accessories, this kit comes with a huge beam rifle, bazooka, two beam sabers, grenade launcher and shield. The bazooka has short and long barrels, and it could be attached to the beam rifle which makes the weapon totally badass!! Grenade launcher could also be attached to the beam rifle and shield. This is not in the manual, but few modification could enable the bazooka to be attached to the shield, as the red Sinanju does in the OVA. The beam saber use yellow clear effects, and the hilts could be stored in the arm. Unfortunately, it doesn't have beam tonfa gimmick as MG, which is I don't really complain about since it's a HG. This kit has 6 sets of hands: a pair of closed hand, a pair of open hand, 1 trigger right hand and open left hand. Anyway, there are only 5 sets of hand guards which is quite weird, but I also don't mind much about it since you could only use 2 hands at a time.

Now let's talk about the bad side. As other Sleeves HG, this kit only uses stickers for the Neo Zeon emblems. Also, the beam rifle lacks parts separation. If you don't like it, you can paint it of though. Lastly, it only comes with sticker, no marking decals at all. Those are the reasons which prompted me to apply custom decal and paint on it.

Badass!!
I used some spare waterslide decals of RG Sinanju and 1/144 HQParts decals to add some details to the kit. For the paint, I used black, grey and red gundam marker to add color separation to the beam rifle. Finally, I applied two layers of matte top coats with Mr. Top Coat for finisher. The final result is so amazing. For posing purpose, I used action base 5 and Kotobukiya red LED sword.








Finally, the verdict. I could say this kit is so great, probably one of the best HG I've ever built. The details are overwhelming, even though there are some areas it lacks but that's still reasonable. The articulation is fantastic with tons of accessories and extra parts, hence it's really fun to play with. Finally, with price tag of 2600 Yen, this kit is well worth of your money and I really recommend it for any gundam/gunpla fans.

-----------------

MSN-06S-2 Sinanju Stein (Narrative Version)

Pros:
  • Beautiful aesthetics, a miniature version of MG Sinanju Stein
  • Great articulation with wide range of movements
  • Lots of accessories, with extra spare parts and options for custom
  • Solid joints, really fun to play with
  • Good price
Cons:
  • No marking stickers
  • Foil stickers for Neo Zeon markings on the collar and arms

Thursday, August 23, 2018

Research Note #16 - WRF Errors Showcase

I've been working with WRF model for about 4 years, which is actually not so long for someone who has been studying atmospheric science for almost 20 years. During that time, I've switched from WRF-EMS (currently known as STRC-UEMS), WRF-ARW and finally WRF-Chem. While it's quite a short period, I've experienced the mess with WRF so many times, and I think it's time to recap those issues, not just for assisting my own future research, but for others who are studying in the same field.

FYI, I've run WRF model using supercomputer of UTokyo, Oakforest PACS, with the total 8208 computation nodes and peak performance of 25 PFLOPS. Anyway, I usually only use 16 nodes with 32 MPI processes for each simulation batch jobs, because I think it's more than enough.

Without further ado, here are the most common errors I've ever experienced with WRF model. Oh yeah, I will not list errors due to typos in the namelist.input (e.g. you forgot to match the grid resolution between namelist.input and namelist.wps, forget to put comma, period etc.).

1. CFL Error


Symptoms: 
  • WRF generates messages such as : "x points exceeded cfl=x in domain d0x at time ...
  • Simulation speed degrades or simulation completely stops.
Causes:
  • Model becomes unstable, mostly because the time-step used is too large for stable solution, especially while using high-res simulation grids.
  • Conflicts among model physics/dynamics/domains configuration.
Solutions:
  • Decrease the time-step (namelist.input > &domain > time_step).  The most common used convention is 6*DX in kilometers. That means, if the grid resolution is 10 km, then use at least 60 seconds time step. If the messages still appear, decrease the time step to 30 or 10 seconds.
  • Check the parameterization/configuration used in namelist.input which could potentially cause conflicts or model crash. I usually discard some parameterization schemes, and check them individually to see if I they are the causes of the crash.        
2. Flerchinger Messages

Symptoms:
  • WRF generates messages such as: "Flerchinger USEd in NEW version. Iterations= x"
  • Simulation still runs but the speed degrades.
  • WRF restart files are not generated.
Causes:
  • It's basically not an error, but a message generates by Noah LSM (namelist.input > &physics > sf_surface_physics), when the model output soil temperature which is super low/negative soil moisture. I experienced this while running simulation over Russia, with lon and lat > 55 degree. 
Solutions:
  • Change the surface physics to other options
  • Change the input data. I changed from GFS FNL ds083.2 into ECMWF ERA-Interim, and I've never met such messages ever again, even if I still use Noah LSM.


3. No WRF Simulation Log (rsl.out or rsl.error) Generated

Symptoms:
  • While running real.exe or wrf.exe, there are no logs of simulation. Instead of log file, the steps are shown on the screen (stdout).
Causes:
  • Well ... while it's quite strange and stupid (which I experienced), but this is absolutely not an error. It happens when you compiled WRF binaries for serial computation, instead of parallel ones (dmpar or smpar).
Solutions:
  • Recompile the model using dmpar or smpar or both, then you'll get your logs back.

4. Real.exe Error : Interpolation Order Error


Symptoms:
  • While running real.exe, the process is stopped at certain point, indicating that there are to few data for the interpolation order with Real.exe
Causes:
  • I'm not so sure about this, but I think that was caused when real.exe finds that the data for vertical interpolation is inadequate for model run. This was happened when I use GFS FNL ds083.2 for simulation over Russia, and I got so many warnings about missing level data, before this error occurred.
Solutions:
  • Change the data. I used ECMWF Era-Interim and the errors were gone.

5. WRF Simulation Sudden Death

Symptoms:
  • Model crashed. Real.exe and Wrf.exe are abruptly stopped, without any error messages in log files. It just stop.
Causes:
  • I hate this error because it might caused by many factors, but mostly because of the conflicts within the model configuration. For example, I was using WSM-3 MP parameterization schemes, with RRTM schemes for LW and SW, with domain over high latitude and complex terrain, 10 km resolution, using several computation nodes, then many strange things happened: the model crashed many times, could only stable while running on single node, etc.  
  • On several cases, it's also caused by too large time-step similar with CFL error.
  • Sometimes, it also occurs if the domain is too large, in particular when grid size < 10 km with complex terrain.
 Solutions:
  • Change the model configuration. For my case, I used Lin MP scheme with new RRTM schemes, and the error was gone.
  • Reduce the time-step in the factor of 2 (half of time-step first, if still not works, try 0.25 of the original time-step, and so on).
  • Reduce the domain size. 

6. Mismatch Landmask ivgtyp
Symptoms:
  • Real.exe crashed, giving error message: 
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: LINE: 2963
mismatch_landmask_ivgtyp
-------------------------------------------

Causes:
  • By far, only occurred while using ECMWF Era-Interim dataset. The reason is unknown. It's documented on WRF-ARW website.  
Solutions:
  • Change the value of 'surface_input_source' on &physics parameter of namelist.input from '3' to '1'

7. Ungrib.exe Segmentation Fault (End Date)

Symptoms:
  • Ungrib.exe crashes at the ungribbing process at the end date, giving error message: "Segmentation fault ..."
Causes:
  • Probably, it has something with computer memory, because when I set ulimit to unlimited, the problem was solved.
Solution:
  • ulimit -s unlimited 

8. Metgrid.exe error in ext_pkg_write_field

Symptoms:
  • Metgrid.exe crashes at the beginning of the process with messages: 'ERROR: Error in ext_pkg_write_field'.
Causes:
  • This will happen when new NCEP GFS data (Version 15.1 or higher) was process using old version of ungrib.exe (< Ver. 4).
Solution:
  • Install Ungrib from WPS Ver.4. (the old geogrid/metgrid still could be used). 

Thursday, August 16, 2018

Gunpla #38 - RG Sazabi WIP and Review


Sazabi will always be one of my favorite mobile suits in Gundam history. Therefore, when Bandai announced they would release it as an RG, I just felt nothing by hype!

On Saturday, August 11, 2018, it's finally released in Japan. I woke up early and rushed to one of the retail stores next to Kashiwa station to check it out. It was a pretty quiet Saturday, probably because most of people in the city traveled back to their hometown to celebrate Obon. Once I got to the store, I checked the shelves only to become disappointed to find no RG Sazabi there. I moved to another store, and again, no Sazabi. I wondered why I couldn't find it, was it sold out already? Here, at 11 AM?  I took a bus to another store, the one which has the most complete gunpla collection in the city, and finally I saw it. I saw the box.





Man, the box is so huge! It just like twice as big as an typical RG box, definitely an MG size. I took one of them, and grab some cash to the cashier. I bought it for 3600 yen, even though the original price is 4500 yen. In Japan, you will get 20-30% discount if you buy gunpla at retail stores, and even more if you buy the newly released kits.

The construction

Now, lets start building this monster. There are 17 runners in the box, quite normal for an RG kit. So why does it has a huge box? I was pretty sure that was because Sazabi itself is a huge mobile suit, and it should be the largest RG ever released to date. Anyway, I noticed something strange with one of the runners.


It's the B runner, the advanced MS joint, which serves as the inner frame for every RG kit. For a massive kit such as Sazabi though, I guess the parts were too few. Only 5 parts on it, and by the looks alone, I could tell that they should be the inner frame for 3 body limbs.

There were nothing special during the build process, except for the inner frame I mentioned above. I found out that Sazabi has 'another' inner frame for the feet and legs which are constructed from other runners, not from B runner. The inner frame was somehow similar with an MG kits. Interesting. The last RG I built was Banshee Norn, thus I don't know if this kind of inner frame has been already applied for RG Talgeese or just started with Sazabi. Nevertheless, the extra inner frames were more solid than the advance MS joint, hence making the feet and legs so sturdy. This is a good sign for the future of RG kits which are infamous for their fragility.




     
The next part to build was the waist unit, and there it went for the first part of B runner. It's one of the biggest parts of the kit, and as MG Sazabi ver Ka, it was packed with so many details on it. I found some sliding mechanisms for the back skirts, but not as extensive as its MG counterpart. The front and side skirts also have rotated clipping connectors which made them articulated really well. One should pay an extra attention while snap-fitting these parts, especially the back skirt, because sometimes, you will find that the parts are seemingly not fitted enough (even though, they are correctly fitted), and start to push or snap the parts too hard. This leads to stress marks or even breaking the parts. I suggest you check the manual carefully and just continue snap fitting other parts if you experience such situations. 



   
Next is the chest unit. Again, it uses an MG-like inner frame as feet and legs. Anyway, I had a small problem while building this part. The body-arm connectors were constructed on vertical pegs, and one should push them down tightly, as far as the parts went (as the manual said). This was where the problem started. It's so difficult to push the parts, and I just didn't want to break them, thus I just pushed them necessarily. Later, I found that the back part could not tightly cover the body because the arm connectors were not tightly pushed down enough. Anyway, problem solved by pushing the arm connectors carefully using a dull surface of my screwdriver. It was scary though.


  
Now, we get to the arms unit. This unit is arguably the most sophisticated part of the kit, because it houses both two main gimmicks of RG Sazabi: open hatch and wide-movement articulation. The remaining pairs of parts of B runner went for the arms unit. As MG ver. Ka, the arms looks very detailed with piston-like parts which extended if when the arms were bent. Similar with the waist unit, the shoulders have clipping connectors which enable the front and back parts to open, hence featuring the open-hatch gimmick.




The last body part is the head, which was I personally thought had the least feature of the kit. It also had open hatch gimmick by moving up and down the face part.



Next, let's build the back pack and funnels. If you have previously built MG Sazabi Ver. Ka, you might experience 'nightmare' while building those parts, especially the funnels. Well, for RG Sazabi, the build process was much more simpler. I could complete the whole parts in less than one hour. The most complicated part to snap-fit was probably the back covers of the back pack. Those parts were needed to be inserted first than rotated to fit in place. I was scared that I will broke the parts, but eventually, it just worked fine. So just stick on the manual and you'll be fine.



The backpack also features open hatch gimmicks by sliding the back covers and funnels launchers.




And finally, the weapons and shield were the last parts to put together. The construction for those parts was somehow very simple. Nothing special here. Ah, and don't forget about that tiny Char Aznable figure ^^.



The Aesthetics 

And now, time for the review.

Speaking of design aesthetics, probably nothing can beat Sazabi, both in its MG (Ver. Ka) and RG forms. This could probably bias since Sazabi is one of my favorite mobile suit. But, come on ... just look at those details, the colors and badassery! I personally prefer the proportion of RG version over MG ver. Ka. While MG looks so bulky, the RG looks much more balanced and muscular, even when open-hatch gimmick is applied. I also love the shield of RG version which has some sharp edges than the more rounded MG one. Anyway, I feel a little bit off with the chest of RG version. I think it's too small compared to other limbs.





There are 3 tones of red with this RG kit, and all three is blending just right. Watching the kit standing with all weapons and decal applied brought really pleasant feeling to the eyes!

Oh yeah, the decal and foil sticker for this kit are pretty good. I was quite anxious before applying them, but it turned out to be working really well, even though I have to trim some quite annoying decal stickers, especially for the front skirt and legs. The markings were quite thin, so if you apply them carefully (and cleanly), you will barely see the edges.    

The Articulation and gimmicks
This is probably where RG Sazabi stands out among the other RG kits. We knew that RG line is infamous due its fragility, even though some kits are proven to be sturdier than the others (e.g. Mk-II, Exia, 00, Qant or Unicorn/Banshee). Despite the massive size, the articulation of Sazabi is amazing. The legs and arms could bent really far, and it still feels sturdy and strong while putting the kit into many kind of pose. I believe this is the work of the new 'unique' inner-frame.








This kit features wide-range movement gimmick, which enables some parts of the body to be extended to improve their movement to certain degree. One clear example of this is the arms. Just look at this:


By opening and re-snapping some 'hatch' points, the hands and arms could extend a little bit further. Finally, the base of hands (trigger and weapon-handle hands) also has special articulation. This is really useful for posing purpose, especially with the beam riffle. Therefore, in contrast with its MG counterpart, there's exactly no problem with holding the beam rifle on the RG version whatsoever.



And of course, there is also the widely anticipated open-hatch gimmick. This gimmick on RG is basically the simplified version of the MG ver. Ka. It applied to fewer parts but much more easier to pull than MG ver. Ka, and I personally felt quite safe to do it without any feels to broke the kit. The most difficult part to open is probably the side skirts, but I think that's not a big deal.

The Accessories
This kit gives you a beam rifle, shield, 4 beam saber hilts (2 are stored inside the arms), 1 beam axe hilt which could be stored in the shield, 3 missile/rocket (in the shield, could be detached), 2 beam saber clear effects, 2 short beam axe effects and 2 long beam axe effects. There are also 2 standard close hands, 1 trigger right hand, 2 melee weapon holding hands and 2 open hands. There are also spare parts for hand guard and hand joint.

And also, don't forget about the tiny Char's figure^^

Verdicts
I will make it short. This is the best RG I've ever built. It's beautiful, massive, badass, sturdy, sophisticated and fully articulated, really easy for posing. The 3-tones red color really stands out, the gimmicks are great and doing just fine. The only thing I don't like is the small chest, but overall, I prefer this version over the MG Ver.ka.

This is arguably the one of the best (if not the best) RG to date, and you should have it! Hands down!






--------------------

MSN-04 Sazabi

Pros:
  • Highly detail design
  • Great articulation gimmicks
  • Sturdy build

Cons:
  • Small proportioned chest