2016年12月19日月曜日

七面鳥の丸焼きをやってみた

人生初、七面鳥の丸焼きをやってみた。

七面鳥はムスリムブッチャーの店で注文。1パウンドあたり$4.85とかなり高いがハラールターキーが手に入るのはビクトリアではおそらくここのみなので仕方ない。パッケージングされたのはこんな感じ↓

  
重さを聞くのを忘れていたが値段は税込でおよそ$70。1パウンドあたりの値段から逆算して約12パウンド(5.5kg)と推測。

家の中も暑くないので室温で1日強かけて解凍。袋から取り出して水洗いして塩胡椒・スパイス等を表面(皮)と皮の内側を手で慎重に引き裂きながら擦り込む(それでも皮が一部破れてしまった。。。)。冷蔵庫に入れて一晩寝かせる。
 翌日、焼き始める一時間半前に冷蔵庫から取り出し(バターが足りなかったので)バターを擦り込み表面にはさらにオリーブオイルもかける。四時間かけて325℉のオーブンで焼く。45分毎にオーブンから取り出してbasting(乾燥・焦げを防ぐために出て来た油脂を表面にかける作業)を行う。付属品の首と肝は(あとでグレービーソースの元となる)油脂と絡めるために底に設置する。

最初の45分ですでに表面が茶色に変わり始めていたので、これでは焦げてしまうと思い、アルミホイルで表面を覆う。
自分で言うのもあれだが初めてにしてはなかなかの出来。タイムリーブを擦り込みすぎたと心配していたがそれほど強くもなかった。塩加減もちょうどいい。

スタッフィング(ドレッシング)は七面鳥に詰めると焼くのが難しくなるので別に用意して作った。セロリがなかったので二種類の玉ねぎを使った。

七面鳥から出て来た油脂を別の鍋に移し塩胡椒で味付けし水で溶かした片栗粉を入れグレービーソースは出来上がり。

他にニューファンドランドの名物、Jigg's dinnerも海塩を代用して作った。これまたちょうどいい塩加減。

丸焼きって作りながら味見とか出来ないので心配やったけどうまく出来て良かった。唯一失敗点を挙げると胸の裏側(底面)付近の肉が一部若干冷たかったので食べなかった。次回は温度をもう少しだけ下げて(300℉?)一時間ぐらい長く焼いてみるといいかも。

2016年11月29日火曜日

T&S damping in NEMO

namelist has two parameters for T&S damping: ln_tsd_tradmp and ln_tradmp.

namelist
ln_tsd_tradmp = .false.   !  damping of ocean T & S toward T &S input data (T) or not (F)
ln_tradmp   =  .true.   !  add a damping termn (T) or not (F)

It's not clear to me the difference of the two parameters.

ln_tsd_tradmp and ln_tradmp
Run1: T & F --> Ran
Run2: T & T --> Ran
Run3: F & T --> ln_tsd_tradmp was force set to T (see notes below) --> Ran aborted due to exceeding zonal current.. skipping.
Run4: T & F but with a restoring time scale of 1 day (this is done to compare the results with Run1 to see if damping was done or not) -->

ocean.output for Run 3
===>>> : W A R N I N G
         ===============

 tra_dmp_init: read T-S data not initialized, we force ln_tsd_tradmp=T

 dta_tsd_init : Temperature & Salinity data
 ~~~~~~~~~~~~
    Namelist namtsd
       Initialisation of ocean T & S with T &S input data   ln_tsd_init   =  T
       damping of ocean T & S toward T &S input data        ln_tsd_tradmp =  T


ncdiff -v tn NAA_00000021_restart_2.nc NAA_00000021_restart_1.nc 2minus1.nc
ncdiff -v tn NAA_00000021_restart_4.nc NAA_00000021_restart_1.nc 4minus1.nc

Run1 and Run2 produced different output, hinting that ln_tradmp needs to be T to activate damping.
Run1 and Run4 are produced the identical output, confirming that ln_tradmp needs to be T to activate damping.

Hence, to activate damping, ln_tradmp needs to be .true. while ln_tsd_tradmp can be .false. (because it will be force set to .true. if ln_tradmp is .true.).

2016年11月28日月曜日

ttest in namelist_ice

Why set ttest? Shouldn't we be creating ice if sst is at freezing point of sea water?


namelist_ice

ttest       =  2.0      !  threshold water temperature for initial sea ice


Source: http://forge.ipsl.jussieu.fr/little_nemo/browser/vendor/nemo/current/NEMOGCM/NEMO/LIM_SRC_3/limistate.F90?rev=2

95

      t_bo(:,:) = tfreez( tsn(:,:,1,jp_sal) ) * tmask(:,:,1)       ! freezing/melting point of sea water [Celcius]
96
97      DO jj = 1, jpj                                       ! ice if sst <= t-freez + ttest
98         DO ji = 1, jpi
99            IF( tsn(ji,jj,1,jp_tem)  - t_bo(ji,jj) >= ttest ) THEN   ;   zidto(ji,jj) = 0.e0      ! no ice
100            ELSE                                                     ;   zidto(ji,jj) = 1.e0      !    ice
101            ENDIF
102         END DO
103      END DO

2016年10月20日木曜日

lbc_lnk in TOP_SRC

In LOBSTER, lbc_lnk is called for the prognostic variables in the uppermost layer only:

LOBSTER/trcbio.F90:            CALL lbc_lnk( zw2d(:,:,jl),'T', 1. )
LOBSTER/trcbio.F90:            CALL lbc_lnk( zw3d(:,:,:,jl),'T', 1. )
LOBSTER/trcbio.F90:            CALL lbc_lnk( trbio(:,:,1,jl),'T', 1. )
LOBSTER/trcexp.F90:      CALL lbc_lnk( sedpocn, 'T', 1. )
LOBSTER/trcini_lobster.F90:      CALL lbc_lnk( cmask, 'T', 1. )

While in PISCES, it is called for the entire water column:

PISCES/p4zsed.F90:         CALL lbc_lnk( zcmask , 'T', 1. )      ! lateral boundary conditions on cmask   (sign unchanged)
PISCES/p4zsed.F90.v1:         CALL lbc_lnk( zcmask , 'T', 1. )      ! lateral boundary conditions on cmask   (sign unchanged)
PISCES/p4zsed.F90.v2:         CALL lbc_lnk( zcmask , 'T', 1. )      ! lateral boundary conditions on cmask   (sign unchanged)
PISCES/trcsms_pisces.F90:        CALL lbc_lnk( trn(:,:,:,jn), 'T', 1. )
PISCES/trcsms_pisces.F90:        CALL lbc_lnk( trb(:,:,:,jn), 'T', 1. )
PISCES/trcsms_pisces.F90:        CALL lbc_lnk( tra(:,:,:,jn), 'T', 1. )
PISCES/trcsms_pisces.F90:           CALL lbc_lnk( trn(:,:,:,jn), 'T', 1. )

While CFC and C14b do not use "lbc_lnk" subroutine.


2016年10月15日土曜日

sendmail

In qsub, 'mail' or 'mailx' command is not available.

Alternatively, I can use 'sendmail' to do the same task as 'mail' or 'mailx'. This is especially useful for Nestor becuase Nestor does not have mail notification option in PBS as of now.

Examples of sendmail:

echo -e "subject \n body message" | sendmail email@email.com

Here, the \n separates the subject and the body message (http://unix.stackexchange.com/a/168233).


The sender is the hostname of the processor (?) you are using: e.g. hermes0199.westgrid.uvic.ca.
Unfortunately, some email client (like my old university's) blocked receiving email from this address for some reason.
So the solution here is the specify the sender (to some existing email address) with -f flag:

echo -e "subject \n body message" | sendmail -f "sender@sender.com" email@email.com

You can also specify the sender name with -F option:

echo -e "subject \n body message" | sendmail -F "Me from Nestor" -f "sender@sender.com" email@email.com

2016年10月13日木曜日

slow because of jasper or MY_TRC?

qstat -u

    2000mb  35:59:59 R  30:13:58

 tail tracer.stat

      9529  0.9203073862E+03
      9530  0.9203655932E+03
      9531  0.9204196679E+03
      9532  0.9204798224E+03
      9533  0.9205345088E+03
      9534  0.9205939773E+03
      9535  0.9206496257E+03
      9536  0.9207078335E+03
      9537  0.9207647118E+03
      9538  0.9208231441E+03

The end time step is 26280, so I killed the process.

This slow computing may be due to MY_TRC. I will check.

model stops running after tra_nxt

On Nestor, the biogeochemical model with MY_TRC stops after this step in ocean.output:

 tra_nxt : achieve the time stepping by Asselin filter and array swap
 ~~~~~~~

tracer.stat only has the output for the first time step.

         1  0.7887250137E+03

This problem still occurs after recompiling the model without MY_TRC, so it's not the problem with MY_TRC.

I copied the source code for TOP_SRC that works on Jasper to Nestor, and tested (b4_tra_nxt_ref_cmoc06.7/EXP01). But the problem still exists. Thus, this might be specific to Nestor.

I increased from procs=12 to =24, but still the model hangs at "tra_nxt".

UPDATE on Oct.16
This issue is fixed. Although I cannot be 100% certain (because of my forgetfulness), this problem might have been due to the compiler option not being correctly set. In particular in arch-nestor_hh.fcm:

%FC                  mpif90 -r8 -i4 -fp-model source

The bolded flags were missing. I should double-check this.

2016年10月11日火曜日

makenemo fails in nestor

I can compile (./makenemo) in Japer, while I cannot in Nestor. With Nestor, I get the following error:

./makenemo -m ifort_hpcnestor_pisces_x -n physics_only_naa

mpif90 -o nemo.exe /home/hhayashi/nemo_eric/CONFIG/physics_only_naa/BLD/obj/nemo.o -L/home/hhayashi/nemo_eric/CONFIG/physics_only_naa/BLD/lib -l__fcm__nemo -shared-intel -mcmodel=medium -L/global/software/netcdf-4.1.3/lib -lnetcdf -lnetcdff
ld: cannot find -ltorque
fcm_internal load failed (256)
gmake: *** [nemo.exe] Error 1
gmake -f /home/hhayashi/nemo_eric/CONFIG/physics_only_naa/BLD/Makefile -j 1 all failed (2) at /g01/home/hhayashi/nemo_eric/EXTERNAL/fcm/bin/../lib/Fcm/Build.pm line 597

torque library does exist:

ldconfig -p | grep libtorque

    libtorque.so.2 (libc6,x86-64) => /opt/torque-2.5.13/lib/libtorque.so.2
    libtorque.so (libc6,x86-64) => /opt/torque-2.5.13/lib/libtorque.so

After some googling, I found the solution (ref: http://stackoverflow.com/a/16710346). I had to explicitly locate the library path for torque in the ARCH file (for %NCDF_LIB):

-L/opt/torque-2.5.13/lib -ltorque



2016年10月10日月曜日

blow up issue solved!

tracer.stat indicates undesirable increase in concentrations of some state variable(s) at the 7th time step:

         1  0.7887250195E+03
         2  0.7887190683E+03
         3  0.8475861522E+03
         4  0.9302648776E+03
         5  0.1044380477E+04
         6  0.1170169324E+04
         7  0.2228768128E+11
         8  0.2853781480E+11
         9  0.5271543990E+11
        10  0.7216373356E+11

After commenting and uncommenting source/sink terms in the equations, I discovered that this was due to fmort1 and fmort2 not property flushed into the water column:

        tra(ji,jj,1,jpgoc) = tra(ji,jj,1,jpgoc) &
                           ! source1: flushing
                           + (1.-f_p2)*flushdia*(1.-frld(ji,jj))*z_ia/e3t(ji,jj,1) &
                           ! source2: linear mortality
                           +0.
!                          + 0.7*fmort1 &
                           ! source3: quadratic mortality
!                          + fmort2


After commenting fmort1 and fmort2 terms above, tracer.stat looks more reasonable:

         1  0.7887289636E+03
         2  0.7887230246E+03
         3  0.7890159536E+03
         4  0.7902228379E+03
         5  0.7905440777E+03
         6  0.7908932570E+03
         7  0.7910913500E+03
         8  0.7913530813E+03
         9  0.7915290453E+03
        10  0.7917645388E+03

2016年10月6日木曜日

generating meteo file for amundsen


for month in `seq 1 12`;do wget --content-disposition "http://climate.weather.gc.ca/climate_data/bulk_data_e.html?format=csv&stationID=1633&Year=2008&Month=${month}&Day=14&timeframe=1&submit= Download+Data" ;done
Other stations in the Amundsen Gulf area:

2016年10月5日水曜日

When all three my_trc components are added, the tracer.stat increases too rapidly:

tail tracer.stat
         1  0.7895863787E+03
         2  0.3124101036E+04
         3  0.1067765821E+13
         4  0.2180091013E+27
         5  0.8173235638E+41

This still occurs even I remove the icedms component:

         1  0.7895863787E+03
         2  0.3056491046E+04
         3  0.1034367164E+13
         4  0.2180090884E+27
         5  0.8173235638E+41

When I removed the chunk of code about ice ablation/accretion, the tracer.stat became normal:

         1  0.7895862638E+03
         2  0.7895870356E+03
         3  0.7913792876E+03
         4  0.7936409329E+03
         5  0.7949360900E+03

Thus, the problem is here:

         ! Lateral accretion/ablation
        IF(frld(ji,jj)-pfrld(ji,jj) > 0.) THEN ! In case of accretion, newly formed ice will have a tracer concentration of an underlying seawater value.
          icechl(ji,jj) = (1.-pfrld(ji,jj))/(1.-frld(ji,jj)+epsilon10)*icechl(ji,jj) + ((1.-frld(ji,jj))-(1.-pfrld(ji,jj)))/(1.-frld(ji,jj)+epsilon10)*trn(ji,jj,1,jpdch)
          iceno3(ji,jj) = (1.-pfrld(ji,jj))/(1.-frld(ji,jj)+epsilon10)*iceno3(ji,jj) + ((1.-frld(ji,jj))-(1.-pfrld(ji,jj)))/(1.-frld(ji,jj)+epsilon10)*trn(ji,jj,1,jpno3)
          icenh4(ji,jj) = (1.-pfrld(ji,jj))/(1.-frld(ji,jj)+epsilon10)*icenh4(ji,jj) + ((1.-frld(ji,jj))-(1.-pfrld(ji,jj)))/(1.-frld(ji,jj)+epsilon10)*trn(ji,jj,1,jpnh4)
        END IF

2016年10月4日火曜日

interesting segfault

I had a segmentation fault which is due to NaN. However, this was interesting because although the IF statement was always false, it gave me segfault because NaN would result if the IF statement was true.. 

        write(numout,*) 'hhpass: nancheck ',(1.-pfrld(ji,jj))/(1.-frld(ji,jj)+epsilon30)
        IF(frld(ji,jj)-pfrld(ji,jj) > 0.) THEN ! In case of accretion, newly formed ice will have a tracer concentration of an underlying seawater value.
          write(numout,*) 'hhpass: inside if statement'
          icechl(ji,jj) = icechl(ji,jj)/(trn(ji,jj,1,jpdch)+epsilon30)!((1.-pfrld(ji,jj))/(1.-frld(ji,jj)+epsilon30)*icechl(ji,jj) + ((1.-frld(ji,jj))-(1.-pfrld(ji,jj)))/(1.-frld(ji,jj)+epsilon30)*trn(ji,jj,1,jpdch)
        END IF


 Update: This seems to have to do with floating points.

Writing out the output for the variables in dinomenator and numerator show a particular floating point (i.e. 14):

 hhpass: pfrld    1.00000000000000
 hhpass: frld    1.00000000000000





In the example above, I tried avoid the division by zero by introducing epsilon number 30 (i.e. 1.e-30), but the division produced NaN:

hhpass: nancheck    NaN

After this, I instead introduced a epsilon number that is smaller than the floating point of the two variables (i.e. 4). Then the division produced zero:

 hhpass: nancheck   0.000000000000000E+000


Epsilon30 worked for biogeochemical tracers. But not for ice physical tracers (probably a specic floating point number is defined in LIM_SRC_2 for these tracers?)

2016年10月3日月曜日

NaN in tracer.stat --> found the problem!

I used to see NaN in the second time step of tracer.stat. In the first time step you dont see Nan because it is the initial condition.

In the second time step, seawater NO3 was NaN because it was exchanging the NaN value coming from the sea ice NO3, which was due to the lack of epsilon number.

For example, the sink for sea ice NO3 due to ice algal uptake is calculated based on the ratio of NO3 and all other available nitrogen (i.e. NO3 and NH4). When NO3 and NH4 are initially set to 0 in the model (for now), the denominator becomes zero, therefore the sink = NaN, therefore the ice NO3 in the next time step as well as the oceanic NO3 became NaN.

So I fixed this by adding a very small epsilon number to avoid this division by zero.

interpolate seawifs onto NAA grid

1) Download the monthly climatology data:
wget http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19972442010273.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19972742010304.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19973052010334.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19973352010365.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19980012010031.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19980322010059.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19980602010090.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19980912010120.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19981212010151.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19981522010181.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19981822010212.L3m_MC_CHL_chlor_a_9km.nc http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/S19982132010243.L3m_MC_CHL_chlor_a_9km.nc

2) Rename the data so that they will appear in the order of months (i.e. from Jan. to Dec.):
for i in $(ls *_MC_*.nc); do `echo "cp $i tmp${i:5}"`;done

ls tmp*.nc
tmp0012010031.L3m_MC_CHL_chlor_a_9km.nc
tmp0322010059.L3m_MC_CHL_chlor_a_9km.nc
tmp0602010090.L3m_MC_CHL_chlor_a_9km.nc
tmp0912010120.L3m_MC_CHL_chlor_a_9km.nc
tmp1212010151.L3m_MC_CHL_chlor_a_9km.nc
tmp1522010181.L3m_MC_CHL_chlor_a_9km.nc
tmp1822010212.L3m_MC_CHL_chlor_a_9km.nc
tmp2132010243.L3m_MC_CHL_chlor_a_9km.nc
tmp2442010273.L3m_MC_CHL_chlor_a_9km.nc
tmp2742010304.L3m_MC_CHL_chlor_a_9km.nc
tmp3052010334.L3m_MC_CHL_chlor_a_9km.nc
tmp3352010365.L3m_MC_CHL_chlor_a_9km.nc

3) Create a new variable called time to each data:
for i in $(ls tmp*9km.nc); do ncap2 -O -s 'time=array(1.,1.,1.)' $i vartime_$i; done

4) Create an unlimited (RECORD) dimension called "time" to each data:
 for i in $(ls vartime_*.nc); do ncecat -u time $i dimtime_$i; done

5) Concatenate the files:
ncrcat -h dimtime_*.nc seawifs_mon_clim.nc

6) Finally use SOSIE to interpolate onto NAA grid:
~/sosie-2.6.4/bin/sosie.x -f namelist.seawifs2naa


2016年9月30日金曜日

lbc_lnk

lbc_lnk is done for all diagnostic variables in LOBSTER, e.g. trcbio.F90:

            CALL lbc_lnk( zw2d(:,:,jl),'T', 1. )

Q: do I need to do this in MY_TRC?

"tra" seems to represent the tracer concentration in the following time step, therefore I need to update tra instead of trn! The words "update the trend" are confusing to me (it seems the time rate of change is represented by tra. rather it should say update tra with the trend (or flux)).

tra, trn, trb for the next time step will be updated by TRP/trcnxt.F90, as well as the OBC and LBC are computed.

Actually, "tra" does represent the time rate of change in tracer concentration. For example PISCES/p4zflx.F90:

            ! compute the trend
            tra(ji,jj,1,jpdic) = tra(ji,jj,1,jpdic) + ( zfld - zflu ) / fse3t(ji,jj,1)

where zfld - zflu represent the flux [mol/m2/s] which is divided by fse3t (vertical scale factor; thickness of first model layer??) [m]. Thus the division gives [mol/m3/s].


NaN in tracer.stat

I finally found the reason for segmentation fault (I think). It is because at least one of the newly added tracers (icechl, iceno3, and/or icenh4 in this case) has value of NaN, as seen in tracer.stat (which calculates sum of all 3d tracers, see ztrai in trcstp.F90):

         1  0.7883947556E+03
         2               NaN

This happens at the second time step. This means that either or both DMSPd or/and DMS becomes NaN in the second time step...

Actually this was not the cause of segmentation fault, as the run passed the second time step when key_my_trc_iceeco was excluded:

         1  0.7883947556E+03
         2               NaN
         3               NaN
         4               NaN
         5               NaN

Anyway, it is good to know that my 3d tracers are erraneous as well :(

2016年9月29日木曜日

time step for tracers in MY_TRC

PISCES/trcini_pisces.F90

rfact = rdttrc(1)

HH this should equal rdt (time step for dynamics) unless different tracer time step is given.

rfact2 = rfact / float (nrdttrc)

HH this would still be rfact unless nrdttrc (time step for biology) is different from tracers.

xstep = rfact2 / rday

HH rday = 86400 sec/day (defined in OPA_SRC/DOM/phycst.F90), so xstep gives the time step in days.. PISCES uses xstep when the rate constant is given in units of d-1. I will avoid using xstep and instead convert the rate constant to s-1 during the initialization as in FABM.

addting a new variable in netcdf

! Re: create new OBC files that include DMS and DMSPd in the water column.

! To run the DMS model, I need to set an open boundary condition for dms and dmspd. For now, I will just create an OBC that has a minimum value (0.01) for all time/space, such as done for some of the PISCES variables (e.g. ZOO). In the current setup, the same OBC files are used (obc_[east,west]_trc_cmoc_y0000m00_canesm.nc) for interannual runs, so I will create two new files (east and west, although they may be identical) that include both dms and dmspd.

! Copy the source OBC files into the tmp folder.
cp obc_east_trc_cmoc_y0000m00_canesm.nc ~/tmp/
cp obc_west_trc_cmoc_y0000m00_canesm.nc ~/tmp/

! Extract the OBC data for ZOO and ZOO2 (which are all constant values of 0.01) and save to a new file.
ncks -v ZOO,ZOO2 obc_east_trc_cmoc_y0000m00_canesm.nc tmp_east.nc
ncks -v ZOO,ZOO2 obc_west_trc_cmoc_y0000m00_canesm.nc tmp_west.nc

! Rename the variables to dms and dmspd.
ncrename -O -v ZOO,dms tmp_east.nc
ncrename -O -v ZOO,dms tmp_west.nc
ncrename -O -v ZOO2,dmspd tmp_east.nc
ncrename -O -v ZOO2,dmspd tmp_west.nc

! Add the new variables to the existing files.
ncks -A -v dms,dmspd tmp_east.nc obc_east_trc_cmoc_y0000m00_canesm.nc
ncks -A -v dms,dmspd tmp_west.nc obc_west_trc_cmoc_y0000m00_canesm.nc

! Rename the files, so that I don't get confused with the source files.
mv obc_east_trc_cmoc_y0000m00_canesm.nc hh_obc_east_trc_cmoc_y0000m00_canesm.nc
mv obc_west_trc_cmoc_y0000m00_canesm.nc hh_obc_west_trc_cmoc_y0000m00_canesm.nc

! Remove the tmp files.
rm tmp_east.nc tmp_west.nc

2016年9月28日水曜日

20160928

When key_my_trc_iceeco is activated, the run stops here (ocean.output):

 trcdit_wr : write NetCDF passive tracer concentrations at            3 time-step
 ~~~~~~~~~

But when I submit the job with "#PBS -l nodes=1:ppn=12" as opposed to proc=12, then the run went one step further:

 trcdit_wr : write NetCDF passive tracer concentrations at            3 time-step
 ~~~~~~~~~
 trcdii_wr : write NetCDF additional arrays at            3 time-step
 ~~~~~~

Actually, I repeated the run with "#PBS -l nodes=1:ppn=12", but this time it did not reproduce the same result as before, but the same result with 'procs=12' case... very strange.



But still being killed due to 174 seg fault and 78 error (not sure what they mean):

forrtl: severe (174): SIGSEGV, segmentation fault occurred

forrtl: error (78): process killed (SIGTERM)

It seems that this happens at the third time step (I tested with "write" statements).

Maybe I need to ask for more procs? Try with procs=24:

The run went bit further.

Now increase vmem=3000mb:

No further progress.. So I don't think it's the lack of memory/processors.

I will look into MY_TRC again..

2016年9月21日水曜日

interpolating sea ice concentration onto NAA grid

1) Download the ice concentration data from  http://nsidc.org/data/G10010

2) I am only interested in satellite data from 1979 to 2013, so extract data only for that time period:
ncea -F -d time,1549,1968 G10010_SIBT1850_v1.1.nc G10010_SIBT1850_v1.1_HH1979_2013.nc

3) Convert the data into NAA grid using SOSIE:
../bin/sosie.x -f namelist.ice2naa

4) Compute the monthly climatology (ref: http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-7.html):
for k in `seq 1 12`; do `echo "ncra -F -d time_counter,$k,420,12 icecon_G10010_SIBT1850_v1.1-naa_icecon.nc4 $k.nc"`; done

5) Concatenate the climatology for each month into a single file (ref: http://research.jisao.washington.edu/data_sets/nco/#example8):
ncrcat -h [0123456789].nc 1[012].nc icecon_mon_clim.nc


2016年9月10日土曜日

Updated python script for Lana DMS climatology csv to netCDF conversion

The script has been updated to:

  • include the time variable to facilitate the SOSIE interpolation.
  • The order of dimensions are set in a way that ferret would recognize them correctly (time, lat, lon) which gets translated in ferret as (L, J, I).
  • NOTE: read_csv function has a flag header, which should be None for my Mac, but 0 for my office computer in order to extract the correct number of data in row (=180). Not sure why, but they behave differently.
  • included the loop to save all 12 months in one file.


Reference used to develop the script: http://qiita.com/okadate/items/954574a95545b06ca257

csv2nc.py

import netCDF4
from pylab import *
from pandas import read_csv

ncout = netCDF4.Dataset('test.nc','w')

fmonth = ['JAN','FEB','MAR','APR','MAY','JUN','JUL','AUG','SEP','OCT','NOV','DEC']

for x in range(12):
data=array(read_csv('../lana_dms_src/DMSclim_'+fmonth[x]+'.csv',header=0))
if x == 0:
dim0 = size(data,0)
dim1 = size(data,1)
lats_out = 89.5 - 1.0*arange(dim0,dtype='float32')
lons_out = -179.5 + 1.0*arange(dim1,dtype='float32')

ncout.createDimension('latitude',dim0)
ncout.createDimension('longitude',dim1)
ncout.createDimension('time',None)

lats = ncout.createVariable('latitude',dtype('float32').char,('latitude',))
lons = ncout.createVariable('longitude',dtype('float32').char,('longitude',))

lats.units = 'degrees_north'
lons.units = 'degrees_east'
lats[:] = lats_out
lons[:] = lons_out

time = ncout.createVariable('time', dtype('int32').char, ('time',))
time.long_name = 'Climatological Month'
time.units = 'days since 1968-05-23 00:00:00'
time[:] = 1 + arange(len(fmonth),dtype='float32')

dms = ncout.createVariable('DMS',dtype('float32').char,('time','latitude','longitude'))
dms.units =  'nmol L-1'

data_all = empty((len(fmonth),dim0,dim1))
data_all[x,:,:] = data
dms[:,:,:] = data_all
ncout.close()

2016年9月8日木曜日

How to convert the original Lana DMS climatology (in the CSV format) into the netcdf format

I used this script (http://stackoverflow.com/q/22933855) as a reference to create my Python script to convert the CSV formatted Lana DMS climatology (http://www.bodc.ac.uk/solas_integration/implementation_products/group1/dms/) into the netCDF format. Here is my script:

import netCDF4
from pylab import *
from pandas import read_csv

ncout = netCDF4.Dataset('test.nc','w')

data=array(read_csv('../dmsclimatology/DMSclim_APR.csv',header=None))
dim0 = size(data,0)
dim1 = size(data,1)
lats_out = 89.5 - 1.0*arange(dim0,dtype='float32')
lons_out = -179.5 + 1.0*arange(dim1,dtype='float32')

ncout.createDimension('latitude',dim0)
ncout.createDimension('longitude',dim1)

lats = ncout.createVariable('latitude',dtype('float32').char,('latitude',))
lons = ncout.createVariable('longitude',dtype('float32').char,('longitude',))

lats.units = 'degrees_north'
lons.units = 'degrees_east'

lats[:] = lats_out
lons[:] = lons_out

dms = ncout.createVariable('DMS',dtype('float32').char,('latitude','longitude'))

dms.units =  'nmol L-1'

dms[:] = data
ncout.close()

If you want to use this script, you would need to make sure you have those three modules and change the file name associated with the read_csv function to your own.

The output looks like this (on the right) and you can confirm that this is consistent with the published figure (on the left). NOTE: the color bar scales are different, so they don't look exactly the same.





2016年6月7日火曜日

k_dmspd

今の所k_dmspdはバクテリアが行うので光が存在する時はほぼ0になるようにしているがこの場合、k_dmspの数値を上げても氷が解けた後の北極の場合光が24時間存在するためdmspdの濃度が思ったよりも下がらない。
dmspd濃度.k_dmsp=3(左)とk_dmspd=13(右)の場合

光によるk_dmspdの影響をもう一度考え直す必要がありそう。細菌は光に対しそこまで柔じゃないのだろう。