コロナウイルス

流石にちょっとぐらい理解しておいたほうが良いかなと思ってネットを巡っていたら良い資料が見つかったので。 

新型コロナウイルスのウイルス学的特徴

https://www.eiken.co.jp/uploads/modern_media/literature/P11-18.pdf

Compile spack packages for generic X86_64

 It seems that Spack automatically generates very optimized binaries (probably with something like gcc -march=native).

This is usually a good thing, but if a cluster consists of several generations of CPUs, this would cause a problem. In my case, the front node is newer than compute nodes, and the spack modules die on compute nodes.

To avoid this, you may want to add the following in ./etc/spack/defaults/packages.yaml.

Then the compiled binaries are for generic x86_64.

packages:
  all:
    target: [x86_64]

Appended on 30/July/2021

It should be better to have a user level configuration rather than changing the global file 
(the global config file will be overwritten with git pull or you will be complained).

$ cat ~/.spack/packages.yaml
packages:
  all:
    target: [x86_64]

https://spack.readthedocs.io/en/latest/configuration.html

Profiling Oct-file

Since Oct file of Octave is used to get a speedup, I think profiling of oct-files is useful, but I have not been able to do so. Oct-file is an executable binary called by Octave, and so, the profilers might be confused.

Recently, I have just found that "Intel Advisor" can get the information of my oct file. In addition, it really gives me the advice to get better performance.

We just need to launch Octave script to get the performance, namely you need to specify the following on Intel Advisor,
Binary: octave or octave-cli,
Option: an Octave script that calls your Oct-file.

That's it!

Compile Octave with intel compiler

I finally found a way to build Octave with intel compiler and mkl.

$ cat conf_ifort.sh

CPPFLAGS=' -I${MKLROOT}/include -I${MKLROOT}/include/fftw' \

LDFLAGS=' -L${MKLROOT}/lib/intel64' \

CFLAGS="-O3 -fPIC -DM_PI=3.1415926535897932384  -I${MKLROOT}/include -I${MKLROOT}/include/fftw" \

CC=icx CXX=icpx F77="ifort" \

../octave-6.2.0/configure --prefix=/path/to/OCTAVE/6.2.0 \

--with-blas="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl" \

--with-lapack="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl" \

--with-fftw3="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl" \

--with-fftw3f="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl" \

--disable-java --enable-static --enable-fortran-calling-convention=gfortran 

bad memory

 I sometimes recall the memory that my former supervisor rejected my proposal (GPU computation), but my stolen idea became vital with one of my colleagues after half a year.

OK, if I did not have any proven record while he had, I should have been convinced, but the truth is the other way round.

Or, some disgusting my colleagues contributed to disturbing my scientific activities.

Even UN is not a fair place.

Illegal instruction by an empty locale????

 I have just got access to a hand-made PC cluster, and I encounter an interesting problem.

A compute node complains of "illegal instruction", while the architecture is almost the same as that of the head node (Sandybridge, and Haswell). Furthermore, I experienced the problem even with binaries compiled on the compute node. That is totally clueless.

When I login (yeah, it is allowed, luckily) to a compute node, I realize that the terminal says

"-bash: warning: setlocale: LC_CTYPE: cannot change locale (ja_JP.utf8): No such file or directory".

I did the following half in doubt, and the "illegal instruction" disappears!;
"export LC_ALL=en_US.utf8"

I do not know what is really going on, but this is my story.

offsetarray as a member of structure in Julia

 I do feel that accessing offsetarray, which is a member of a structure in Julia, is extremely slow.

In my case, I use a staggered grid in a FDTD code, and defined a structure as;

struct grid

    p :: OffsetArray{Float64,2}

    vx:: OffsetArray{Float64,2}

    vy:: OffsetArray{Float64,2}

end

then accessed like (output, input, resOfCalcF are all "grid".)

for j in -m+1:gridParam.ny+m

    for i in -m+1:gridParam.nx+m

         output.p[i,j] = input.p[i,j] + coef*resOfCalcF.p[i,j]

    end

end

It seems that Julia cannot determine the type of ".p" and this causes the type-instability.

To avoid this, I needed to cast type as 

op = parent(output.p)::Matrix{Float64}

ip = parent(input.p)::Matrix{Float64}

rp = parent(resOfCalcF.p)::Matrix{Float64}

and the array starts from 1 (the loop starts from 2, because the outer most layer is just a dummy)

for j in 1+1:gridParam.ny+m+m+1

    for i in 1+1:gridParam.nx+m+m+1

         op[i,j] = ip[i,j] + coef*rp[i,j] :: Float64

    end

end

I have not measured the speed-up, but probably x10 - x100 speedup is obtained.

ジム再開/Re-opening of gyms in Vienna

 5月19日から3G(陰性証明書/ワクチン接種証明書/罹患証明書の略らしい)を持っていればジムに入れるようになりました。おかげで首の調子もだいぶ戻ったし、血圧も一気に下がった。これから徐々に制限が解除されていくようだけれど、3G所持じゃないとダメな行動が広がるということでもあり、早めにワクチン接種したい。

From the 19th of May, the gyms in Vienna were allowed to re-open, but for those who have 3G certificates (certificates of negative/vaccinated/recovery). Because of the lack of exercise, my neck started complaining to me, and I got hypertension. after a couple of weeks, they are getting better. importance of exercise :)

Getting the negative certificate is not difficult whilst a bit annoying. I may wish to get vaccinated soon.