Monday, March 5, 2018

Gunpla #34 - RG Unicorn Gundam 02 Banshee Norn

When Bandai firstly announced RG Unicorn Gundam for release in 2017, I was among the most hyped people in the world and even able to get the first batch kit (because I live in Japan), the premium unicorn mode box. Sadly, I was too busy for completing the kit because of my studies, experiments and exam. The right leg and two feet were the only parts of the kit I could finish.

Unicorn, still in 'development stage' since September 2017
Therefore, when Bandai announced that they will release RG Banshee in February 2018 which was coincident with my 'free' time, I knew that I shouldn't let the chance went away. I got another premium unicorn mode box, this time for the Banshee. Seriously, there were no differences whatsoever between normal and premium box kit except for the picture on them, but of course, the 'premium' word alone is enough for the die hard fans to hunt for the kit. Some of them just for collection, while the others took further step: re-selling the kit with higher price on many auction sites.
Banshee with its thicc premium box
 I bought the Banshee at a retail store in Kashiwa with just 3000 Yen, which is 25% cheaper than the normal price. I haven't checked it, but I noticed the box was slightly bigger than the unicorn one, indicating more parts inside it. It housed 19 runners in total, and based on the name plates, we knew that 9 of them were newly molded for the Banshee, which was really a good thing. Design wise, Banshee was practically identical to unicorn, with slight modification on some body parts. The new additions were the extra accessories for the Norn upgrade which includes Armed armor DE/XC, revolver launcher, beam jutte and its effect part.

The building process itself was quite similar with unicorn. Extra time though was needed to complete the extra parts. Due my office duties, it took around one week to finish the kit. Every thing was smooth and straightforward. Extra care however, should be taken in order to assemble the head unit because there were so many small parts, in particular with the horn around Banshee's elaborate v-fin.

Once finished, the completed product never stopped to amaze me. It really was a marvel of gunpla design I've ever seen. The detail was so great with lots of panel lines and multiple color separation all over Banshee's body. In its unicorn mode, Banshee looked so compact, robust and much more modern (in my opinion), but once it transformed into Destroy mode, gone the minimalist looks, replaced with the badass and classic gundam persona. The transformation was quite simple and secure since it shared the same inner frame with Unicorn. The articulation was also great for an RG kit. The armed armor XC on the backpack also articulated really well in both unicorn and destroy mode.

One of my favorite new accessories was armed armor DE, which is basically an upgrade for the shield to make it meaner and bigger than before. The enormous shield also had a special connector for attaching the shield onto Banshee's back for extra propulsion (just like TR-1 Hazel custom). Other than armed armors, the kit also introduced revolver launcher with beam jutte and its effect parts. Three pairs of hand are provided by this kit: standard closed, open closed (for beam magnum and beam sabers/jutte) and open hands. With the price 200 yen more expensive than the original unicorn, I could say that Banshee had more values with its extra accessories. The decal stickers were also pretty good and not hinder much of the original appearance of the kit. You also get extra parts from the RG unicorn if you want to make a normal/novel Banshee instead of norn. The only accessory missing from RG unicorn was the bazooka and storywise, it's reasonable.

The only downside of this kit was probably the golden parts and I guess anybody knows why. If you want to have more accurate color, I suggest to repaint the golden parts.  Also, it's unfortunate that this kit doesn't include armed armor VN/BS to make the original Banshee from OVA, and I'm pretty sure that Bandai planned to releasethem as p-bandai exclusive. Other than that, everything came with this kit looks just fine.

The verdict, this kit was fantastic, and in term of design, I think it's the best RG ever made by Bandai. It's slightly more valuable than the RG Unicorn due to the price, accessories and gimmicks. If you don't have RG Unicorn yet or you have to choose only one, I strongly recommend you to get this kit instead of unicorn.


RX-0 [N] Unicorn Gundam 02 - Banshee Norn

  • Everything except for golden parts
  • Nothing except for golden parts         

Thursday, February 22, 2018

Research Note #9 - Useful Linux Commands for Works

Note: This list could be updated anytime.
Latest update: Feb 22, 2018

1. Show, set and unset the environment variables

$ env (bash)
$ setenv (tcsh, csh)

$ export test=something (bash)
$ setenv test something (tcsh, csh)

$ unset test (bash)
$ unsetenv test (tcsh, csh)

2. Module operation for environment variables

$ module avail (show all available module)
$ module list (show loaded module)

$ module load moduleA (load moduleA into environment variables)
$ module purge moduleA (purge/unload moduleA from environment variables)

3. Run configuration script (bash)

$ . ~/.bashrc

4. Show the type of current active shell

$ echo $0

5. System information (cpu, machine, architecture, distribution)

$ lscpu (shows cpu/socket, cores, threads \ total cpu = sockets x cores x threads)
$ uname -r (shows kernel version)
$ uname -m or uname -arch (shows whether linux is 32-bit or 64-bit)
$ lsb_release -a (shows distribution release name)

6. Renaming wrfout files from UPP with 1 or 2 digits f hour into 3 digits f hour (bash)

$ for f in WRFPRS_d01.[0-9]*; do mv $f `printf WRFPRS_d01.%03d $((10#${f#WRFPRS_d01.}))`; done

7. Counting number of files in a directory from ls command 

$ ls -1 | wc -l

8. Checking memory use

$ top
$ free -mts 10 (shows the current total memory in megabytes, updated every 10 seconds)

9. Suspending a running program, then run it in background or foreground

$ jobs  (showing all jobs, indicated with number in square brackets)
$ bg %1(run job 1 in background)
$ fg %1 (run job 1 in foreground)
$ ./wrf.exe & (run wrf.exe in background)

10. Screen for multisession ssh-connection
$ screen (Open new screen session)
$ ctrl-a (Shows control command)
$ ctrl-a c (Open new screen window)
$ ctrl-a d (Detach screen window)
$ ctrl-a n (Move to next screen window)
$ ctrl-a p (Move to previous screen window)
$ exit (Exit current screen session)
$ screen -r (Retrieve any running screen session)

11. Making GIF animation with ImageMagick
$ convert -delay 25 -loop 0 *.png contoh.gif (makes a contoh.gif from all png file in current directory with infinite loop and 0.25s delay/frame)

Wednesday, February 21, 2018

Gunpla #33 - HGGO Gundam Local Type (Rollout Color)

I have a bunch of kits from Gundam The Origin series, but this is the first one I've officially built. When Bandai announced the first Gundam Local Type (the white-blue one) I was thinking like "Oh, the first gundam of the series, I will buy it", but the hefty price held me up from grabbing the kit, and now, I could say that I've never regretted that decision.

Like a common P-Bandai kit, Gundam Local Type (rollout color) is basically a recolor of Gundam Local Type North American type which was released as retail kit. No new molds added whatsoever with the only difference on the marking sticker. It's a little bit expensive than the retail version though. The only reason I chose the P-Bandai version was because of its color. I thought the yellow color scheme stands out more as it reveals the panel lines which were hindered by the black of retail version. I also like the "Heavy-equipment" and "Test-type" color theme as it looks much more of a prototype mobile suit. Moreover, the yellow gundam is rare, isn't it?

As it was my first Gundam kit from the Origin series, I could not compare it directly with the other HGGO Gundams. Anyway, because they share the same molds, I think the articulation is pretty much the same with its retail counterparts, which I found very good as it could do some nice poses. This was also the first build which I tried to customize by trimming the v-fin and cutting the front skirt in half.

I really like this kit, especially the accessories. It came with shoulder canon, machine gun, shield, 3 beam saber hilts, 2 beam saber effects. Unfortunately, there's only 1 extra hand for holding the machine gun. Anyway, Bandai provides us with 2 connectors to attach either machine gun or shield at the backpack. Since it shares some molds with the normal gundam local type, we also get the backpack from the previous release and spare parts for the chest vent. The marking stickers is also nice and blending better than the retail one. The only complaint I have was the ankle armors which were not movable as it molded in one with the leg parts. I also omitted the horizontal stickers for the arms and thighs as I thought they are giving too much retro feels to the kit. 

The conclusion is, this kit is very nice. Indeed, it's not the best out of the Origin series, but in terms of color scheme and marking sticker, I personally think it's definitely better than the American type version.  


RX-78-01 [N] Gundam Local Type (Rollout color)

  • Cool color schemes
  • Nice accessories and marking seals 
  • Good articulation
  • Lack of extra hands
  • Unmovable ankle armor

Friday, January 19, 2018

Research Note #13 - WRF-ARW, NetCDF 3.6.3 and ARWPost Installation

One thing I would anxiously like to check since beginning WRF-CHEM study is whether the output could be post-processed by ARWPost, one of the original post-processor of WRF-ARW. While ARWPost could only provide limited diagnostics of the model output compared to UPP, it's definitely much more simple and straightforward. Moreover, the failure of UPP to process the chemical fields from WRF-CHEM output really urged me to check it out. 

After the first try on FX-10, I found out that the tool was outdated. The latest version was released in 2011 and I couldn't install it using NetCDF 4.4 library. I somehow managed to install it using the older NetCDF (version 3.6.3), but the tool failed to read WRF-CHEM outputs. Nevertheless, after switching from FX-10 to O-PACS, I would like to try installing it once again.

Before installing the tool, I tried to find out the cause of failure. The following were my hypothesis:
  • ARWPost program uses old NetCDF functions in the source code, hence failing the installation when used the latest NetCDF libraries.
  • ARWPost program could only read WRF-ARW instead of WRF-CHEM because the difference of the output fields between those two.
In order to prove those hypothesis, I re-installed WRF model once again, this time without CHEM add-on (original WRF-ARW), in another directory. After the model was successfully compiled, I tried to install ARWPost. For the first try, I used the original NetCDF (version 4.4), and it failed like last time. Then I installed NetCDF 3.6.3 and used the library for ARWPost installation. This time, it worked, the compilation was successful. So, ARWPost did indeed only worked with older NetCDF. While NetCDF supports backward compatibility, the reason why ARWPost could not be installed with older NetCDF functions still remained a mystery for me.

The next one was to find out whether ARWPost could read either WRF-ARW or WRF-CHEM output, or both of them. I run WRF-ARW first and read the output with ARWPost, and it worked flawlessly. Next, reading WRF-CHEM output.

  ARWpost v3.1

FOUND the following input files:


   WARNING --- I do not recognize this data.
               OUTPUT FROM *             PROGRAM:WRF/CHEM V3.8.1 MODEL
               Will make an attempt to read it.

 Processing  time --- 2017-11-01_00:00:00
   Found the right date - continue
 WARNING: The following requested fields could not be found

 Processing  time --- 2017-11-01_01:00:00
   Found the right date - continue

 Processing  time --- 2017-11-01_02:00:00

   Found the right date - continue


Processing  time --- 2017-11-02_00:00:00
   Found the right date - continue

DONE Processing Data

CREATING .ctl file

!  Successful completion of ARWpost  !

Surprisingly, It worked for both model output and the version difference of NetCDF had no effect at all. It sure showed some warning when it read the output, but overall, the post-processing was successful. Anyway, the best news is, it could read all chemical fields in the output file. This is some fields from the output CTL.

PM2_5_DRY     24  0  pm2.5 aerosol dry mass (ug m^-3)
PM10          24  0  pm10 dry mass (ug m^-3)
DMS_0          1  0  dms oceanic concentrations (nM/L)
PHOTR201      24  0  cl2 photolysis rate (min{-1})
PHOTR202      24  0  hocl photolysis rate (min{-1})
PHOTR203      24  0  fmcl photolysis rate (min{-1})
so2           24  0  SO2 mixing ratio (ppmv)
sulf          24  0  SULF mixing ratio (ppmv)
dms           24  0  DMS mixing ratio (ppmv)
msa           24  0  MSA mixing ratio (ppmv)
P25           24  0  other gocart primary pm25 (ug/kg-dryair)
BC1           24  0  Hydrophobic Black Carbon (ug/kg-dryair)
BC2           24  0  Hydrophilic Black Carbon (ug/kg-dryair)
OC1           24  0  Hydrophobic Black Carbon (ug/kg-dryair)
OC2           24  0  Hydrophilic Black Carbon (ug/kg-dryair)
DUST_1        24  0  dust size bin 1: 0.5um effective radius (ug/kg-dryair)
DUST_2        24  0  dust size bin 2: 1.4um effective radius (ug/kg-dryair)
DUST_3        24  0  dust size bin 3: 2.4um effective radius (ug/kg-dryair)
DUST_4        24  0  dust size bin 4: 4.5um effective radius (ug/kg-dryair)
DUST_5        24  0  dust size bin 5: 8.0um effective radius (ug/kg-dryair)
SEAS_1        24  0  sea-salt size bin 1: 0.3um effective radius (ug/kg-dryair)
SEAS_2        24  0  sea-salt size bin 2: 1.0um effective radius (ug/kg-dryair)
SEAS_3        24  0  sea-salt size bin 3: 3.2um effective radius (ug/kg-dryair)
SEAS_4        24  0  sea-salt size bin 4: 7.5um effective radius (ug/kg-dryair)
P10           24  0  other gocart primary pm10 (ug/kg-dryair)

That was really good since ARWPost could also interpolate sigma level from WRF output into pressure level. It will make my job much easier in the future. After opened it on GrADS:

The conclusion is, while it can only work with older NetCDF libraries (unless you modify the source code), ARWPost could read the model output, as long as it uses the same dynamic solver (ARW). Anyway, I still have no idea why it couldn't read WRF-CHEM output on FX-10.


Wednesday, January 17, 2018

Research Note #12 - Installing WRF-CHEM on Oakforest-PACS

This is basically the same with normal installation except for some modifications.

1. NetCDF Libraries
Because Oakforest-PACS (O-PACS) has already had NetCDF libraries (C, Fortran and C++), we don't need to install them. We just to have load the modules into the environment variables. 

$ module load netcdf
$ module load netcdf-fortran
$ module load netcdf-cxx

Since WRF installer needs all of them at once, it's better to copy the NetCDF files into a directory in parallel storage, then set the path to that directory and put it into bash_profile file. To copy the files, check the environment variables which contains entry "netcdf". Merge directories of all netcdf for each compiler into one, hence we'll get a single netcdf directory needed for WRF installer.

$ env | grep netcdf

$ cp <original netcdf dir> <new dir>
$ cp <original netcdf-fortran dir> <new dir>
$ cp <original netcdf-cxx dir> <new dir>

Let's say the new netcdf directory is at /work/gi55/c24223/libs/netcdf

export PACSLIB=/work/gi55/c24223/libs
export NETCDF=$PACSLIB/netcdf
export PATH=$NETCDF/bin:$PATH

2. MPI Library
O-PACS will load Intel MPI (impi) by default, thus we also don't need to install MPICH. Just set the directory of impi binaries (which contains mpicc, mpiexec etc) into environment variables and put it inside the bash_profile. The trick is basically same with NetCDF libraries, but this time, no need to copy the files because impi only has a single directory for all compiler.

$ env | grep impi

export mpi=/home/opt/local/cores/intel/impi/2018.1.163/bin64
export PATH=$mpi:$PATH

Now, reload the bash_profile script to get the changes.

3. Compiling WRF
It's better to compile WRF first, before installing any other libraries for WPS (zlib, libpng and JasPer). The main reason is, in order to install those WPS libraries, we should set up some environment variables which may mess up the WRF compilation (LD_LIBRARY_PATH, CPPFLAG and LDFLAGS).

$ export WRF_CHEM=1
$ export WRF_EM_CORE=1
$ export WRF_NMM_CORE=0
$ tar -xzvf WRFV3.8.1.TAR.gz
$ cd WRFV3/
tar -xzvf WRFV3-Chem-3.8.1.TAR.gz
$ ./clean -a
$ ./configure

Select the dmpar option with intel compiler Xeon AVX mods and basic nesting, then compile em_real.

18. (serial)  19. (smpar)  20. (dmpar)  21. (dm+sm)   INTEL (ifort/icc): Xeon (SNB with AVX mods)

$ ./compile em_real >& compile.log &

Make sure the compilation is successful.

build started:   Tue Jan 16 13:26:53 JST 2018
build completed: Tue Jan 16 14:11:22 JST 2018

--->                  Executables successfully built                  <---

-rwxr-x--- 1 c24223 gi55 65532338 Jan 16 14:11 main/ndown.exe
-rwxr-x--- 1 c24223 gi55 65463925 Jan 16 14:11 main/real.exe
-rwxr-x--- 1 c24223 gi55 64466197 Jan 16 14:11 main/tc.exe
-rwxr-x--- 1 c24223 gi55 75598185 Jan 16 14:10 main/wrf.exe


4. Zlib, Libpng and JasPer libraries
Because the libraries will be compiled and installed using intel compilers, we should set the environment variables.

$ export CC=icc
$ export FC=ifort
$ export CXX=icpc
$ export F77=ifort
$ export FCFLAGS=-axMIC-AVX512
$ export FFLAGS=-axMIC-AVX512

Install all libraries in $PACSLIB directory.

$ tar -xzvf zlib-1.2.11.tar.gz
$ tar -xzvf libpng-1.6.34.tar.gz
$ tar -xzvf jasper-1.900.1.tar.gz

The configuration and installation of each libraries are almost same. Before installing zlib, set environment variables for dynamic library linker and c pre-processor.

$ export LDLIB=-L$PACSLIB/grib2/lib
$ export CPPFLAGS=-I$PACSLIB/grib2/include

Then install each library with the following steps (zlib first, then libpng and JasPer):

$ ./configure --prefix=$PACSLIB/grib2 
$ make
$ make install

5. Compiling WPS
Before compiling WPS, exit and re-login the shell. It's needed to return the environment variables of LDLIB and CPPFLAGS back to their original states with the entries loaded by O-PACS.

Set environment variables for JasPer:

export JASPERLIB=$PACSLIB/grib2/lib
export JASPERINC=$PACSLIB/grib2/include

Then add grib2 lib directory as well as NetCDF lib directory into the existed LD_LIBRARY_PATH.

export LD_LIBRARY_PATH=/home/opt/local/cores/intel/impi/2018.1.163/intel64/lib: <many directories>:/work/gi55/c24223/libs/grib2/lib:/work/gi55/c24223/libs/netcdf/lib

Then configure using intel compiler with serial configuration.

$ tar -xzvf WPSV3.8.1.TAR.gz
$ cd WPS
$ ./clean -a
$ ./configure
$ ./compile

Check if the compilation successfully generates geogrid.exe, ungrib.exe and metgrid.exe.

lrwxrwxrwx 1 c24223 gi55 23 Jan 16 15:08 geogrid.exe -> geogrid/src/geogrid.exe
lrwxrwxrwx 1 c24223 gi55 23 Jan 16 15:09 metgrid.exe -> metgrid/src/metgrid.exe
lrwxrwxrwx 1 c24223 gi55 21 Jan 16 15:09 ungrib.exe -> ungrib/src/ungrib.exe

For the last measure, check the library dependency of ungrib.exe and the other two executables.

$ ldd ungrib.exe =>  (0x00007fff239f0000) => /work/gi55/c24223/libs/grib2/lib/ (0x00007f3555e64000) => /work/gi55/c24223/libs/grib2/lib/ (0x00007f3555c45000) => /lib64/ (0x00007f3555943000) => /lib64/ (0x00007f3555727000) => /lib64/ (0x00007f3555366000) => /lib64/ (0x00007f3555150000) => /lib64/ (0x00007f3554f4c000) => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/ (0x00007f35549be000) => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/ (0x00007f355330b000) => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/ (0x00007f3552f97000) => /home/opt/local/cores/intel/compilers_and_libraries_2018.1.163/linux/compiler/lib/intel64/ (0x00007f3552d2a000)
        /lib64/ (0x00007f35560b3000)

If all library found (no 'library not found'), then the compilation is successful.

Tuesday, January 16, 2018

Research Note #11 - Running WRF-CHEM on Oakforest-PACS

After so many compiling issues with WRF-CHEM installation on FX-10 since the beginning of this year, I started to change my attention to Oakforest-PACS (O-PACS) super computer. Just reading the specs, O-PACS definitely looks much more promising than FX-10: newer processors, (much) more cores and threads, more memory, twice as many nodes as FX-10 and the best of all; intel compilers! While not getting used as GCC, I had few experiences with intel compilers, especially ifort, and they're definitely way better than Fujitsu original compilers in term of compatibility with UNIX/Linux software development. 

Another unexpected thing which convinced me to switch to O-PACS was an email I received last friday. It said (in Japanese) that FX-10 service will be stopped after March 2018. Well, that's just like pouring salt on my food. I've done with FX-10. 

And that's it. In the early morning, I started using O-PACS and installing WRF-CHEM, and if it succeed, I would try to run it using parallel jobs with the compute node of the super computer. Guess what? Not only succeed installing the model, I also successfully run it with MPI and multi-nodes, and those were happened in just one day. While the installation itself was not perfectly smooth due to library linker issue and run-time stack problems, the model could run well afterwards. I will post the installation details soon.

There are several things I would like to highlight for running WRF-CHEM on compute node of O-PACS:
  • Number of processes per node affects the model processing time more than the number of nodes used. Using fewer nodes with more processes could significantly decrease the time consumption than using more nodes with fewer processes.
  • Number of nodes affects the consumption of token much. Using more nodes with fewer process was way more expensive than using fewer nodes with more processes.

Just take a look at the picture above. Job 1595130 (the third from bottom) was submitted to use 64 nodes and 8 processes per node, while job 1595143 (the bottom-most) was submitted to use (only) 16 nodes but has 32 processes per node. The total processes between the two jobs were same: 512 (64x8 and 16x32), the elapse times were almost same as well: around 10 minutes. How about the token consumed? Were they similar? Well ... not so much.

It's obvious that job 1595130 (more nodes, fewer processes) consumed token 4x more than job 1595143 (fewer nodes, more processes). Or maybe that's because I used different resource group?Well, we'll find out soon ...

Nevertheless, at least, starting from today, I can run the model using the full capabilities of one of the fastest super computers in the world. Yay !!!

Finally, I can concentrate more on the upcoming exam on Feb 7.

Time to sleep for more works tomorrow ...