spin-polarized and spin-orbit calculations on a gold dimer crash

[Andrés Aguado]

Hi,

I am using siesta-4.1-b3 version. I am calculating the gold dimer as a simple test of my pseudo and basis set. I have done all the main tests using a non-polarized calculation as Au_2 is obviously non-polarized. I found no problems at all. Then I wanted to see the effect of S-O coupling, but I first tried a spin-polarized calculation just as a sanity test. Both calculations (either spin-polarized or spin-orbit) proceed apparently well and the SCF convergence is reached. Just after that, when I guess the code prints out the final information (energy decomposition, dipole moment, etc) the code crashes, both in parallel and in serial (in serial I can read "Bus error"; in parallel not much information).

I attach both the psf file with the pseudo and the fdf file below. I have checked that the mistake is only in the "Spin" order. If you set "Spin non-polarized" it works. If you just change this to "Spin polarized" it crashes.

Any help will be appreciated. I'm not sure of this is a bug of a compiling problem, but the code compiled without any problem. And the spin-unpolarized calculation gives almost exactly the same result as 4.0.2 version, so it seems OK.

Thanks in advance

[Nick Papior (nickpapior)]

Could you try the same calculation with this source:

https://bazaar.launchpad.net/~siesta-maint/siesta/rel-4.1/tarball/947?start_revid=947

In case the crash still occurs, could you please provide additional details as outlined here:

https://answers.launchpad.net/siesta/+faq/2779

[Andrés Aguado (aaguado)]

Thanks a lot for you help, Nick, I appreciate it.

The new code that you passed to me produces a compiler error, when I use
exactly the same arch.make with which I compiled the previous version. I'm
attaching my arch.make file. I'm also attaching "ttt" file where you can
see the compiling error I found after typing "make". The problem occurs in
m_pivot_methods, and apparently is related with using an interface name as
an argument in a subroutine call. I checked that the routine
m_pivot_methods is different in the previos siesta-4.1--736 version as
compared to the actual version. The previous version gave no
compiling problems.

So I could not test yet the new version on the gold dimer. I would
appreciate again some help. Thanks in advance!

......................................................................

Some details about the exact version I was using yesterday, as given at
the beginning of the output file (I forgot to provide this information in
my previous mail):

Siesta Version: siesta-4.1--736
Architecture : intel9-ict3
Compiler flags: mpiifort -v -xW -mp -tpp7 -O3
PP flags : -DFC_HAVE_ABORT
Libraries : -L/opt/intel/ict/3.0/cmkl/9.0/lib/em64t -lmkl_scalapack
-lmkl_blacs_intelmpi220 -lmkl_lapack -lmkl_em64t -lguide -lpthread -lrt
-lsvml
PARALLEL version

Best wishes,

Andres Aguado

On Thu, 26 Jul 2018, Nick Papior wrote:

> Could you try the same calculation with this source:
>
> https://bazaar.launchpad.net/~siesta-
> maint/siesta/rel-4.1/tarball/947?start_revid=947
>
> In case the crash still occurs, could you please provide additional
> details as outlined here:
>
> https://answers.launchpad.net/siesta/+faq/2779
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1783785
>
> Title:
> spin-polarized and spin-orbit calculations on a gold dimer crash
>
> Status in Siesta:
> New
>
> Bug description:
> Hi,
>
> I am using siesta-4.1-b3 version. I am calculating the gold dimer as a
> simple test of my pseudo and basis set. I have done all the main tests
> using a non-polarized calculation as Au_2 is obviously non-polarized.
> I found no problems at all. Then I wanted to see the effect of S-O
> coupling, but I first tried a spin-polarized calculation just as a
> sanity test. Both calculations (either spin-polarized or spin-orbit)
> proceed apparently well and the SCF convergence is reached. Just after
> that, when I guess the code prints out the final information (energy
> decomposition, dipole moment, etc) the code crashes, both in parallel
> and in serial (in serial I can read "Bus error"; in parallel not much
> information).
>
> I attach both the psf file with the pseudo and the fdf file below. I
> have checked that the mistake is only in the "Spin" order. If you set
> "Spin non-polarized" it works. If you just change this to "Spin
> polarized" it crashes.
>
> Any help will be appreciated. I'm not sure of this is a bug of a
> compiling problem, but the code compiled without any problem. And the
> spin-unpolarized calculation gives almost exactly the same result as
> 4.0.2 version, so it seems OK.
>
> Thanks in ...

[Nick Papior (nickpapior)]

The error you see is a compiler mistake. I will try and circumvent this in the coming weeks, but I don't have time currently (and I have no ways of checking this because you are using an old compiler version).

I would recommend you trying to compile with a later intel version, or a recent gnu compiler.

[Nick Papior (nickpapior)]

Perhaps it is not difficult to fix. Could you try this:
https://bazaar.launchpad.net/~siesta-maint/siesta/rel-4.1/tarball/949?start_revid=949

[Andrés Aguado (aaguado)]

Dear Nick,

thanks again. I have made some progress. With the new code (version r949)
that you passed to me the compiler worked perfectly. Moreover, now the
spin polarized calculation on the Au_2 dimer does not crash, and produces
the same result as the non-polarized calculation, as expected as the
molecule is not polarized.

However, the spin-orbit calculation still crashes after the SCF cycle
ends. I'm attaching the relevant input and output files to see if you also
reproduce the problem. I noticed weird things, some of them more physical
than computational:
·Before crashing the code prints out the forces. The atomic configuration
  has zero forces at the scalar relativistic level, and S-O effect should
  be a small correction. However, the forces at that atomic configuration
are huge, bigger than 100 eV Ang. It makes not much sense.
·It seems that the orbitals are not evenly distributed between the four
nodes. I'm not sure if this is an error or it is the intended way?

I know that S-O is still under development and it may be normal to have
some errors. I also read in the manual that the S-O flag does not work yet
with optimizations. Maybe this implies that the forces can be non sense?

Thanks in advance for any help.

Andres Aguado

On Sun, 29 Jul 2018, Nick Papior wrote:

> Perhaps it is not difficult to fix. Could you try this:
> https://bazaar.launchpad.net/~siesta-maint/siesta/rel-4.1/tarball/949?start_revid=949
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1783785
>
> Title:
> spin-polarized and spin-orbit calculations on a gold dimer crash
>
> Status in Siesta:
> New
>
> Bug description:
> Hi,
>
> I am using siesta-4.1-b3 version. I am calculating the gold dimer as a
> simple test of my pseudo and basis set. I have done all the main tests
> using a non-polarized calculation as Au_2 is obviously non-polarized.
> I found no problems at all. Then I wanted to see the effect of S-O
> coupling, but I first tried a spin-polarized calculation just as a
> sanity test. Both calculations (either spin-polarized or spin-orbit)
> proceed apparently well and the SCF convergence is reached. Just after
> that, when I guess the code prints out the final information (energy
> decomposition, dipole moment, etc) the code crashes, both in parallel
> and in serial (in serial I can read "Bus error"; in parallel not much
> information).
>
> I attach both the psf file with the pseudo and the fdf file below. I
> have checked that the mistake is only in the "Spin" order. If you set
> "Spin non-polarized" it works. If you just change this to "Spin
> polarized" it crashes.
>
> Any help will be appreciated. I'm not sure of this is a bug of a
> compiling problem, but the code compiled without any problem. And the
> spin-unpolarized calculation gives almost exactly the same result as
> 4.0.2 version, so it seems OK.
>
> Thanks in advance
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/siesta/+bug/1783785/+subscriptions
>

[Nick Papior (nickpapior)]

Could you try and add this to your arch.make:

state_analysis.o: state_analysis.F
        $(FC) -c $(FFLAGS_DEBUG) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $<

If you still have problems you should carefully follow the instructions here:

https://answers.launchpad.net/siesta/+faq/2779

such that we can use the debug options.

[Andrés Aguado (aaguado)]

hi again,

that solved the crash problem. Now the calculation finish properly.
Thanks!

The physical problem remains. The forces are unphysical. I have tried to
optimize the bond length, and as the atoms move in the direction of the
forces (to contract the bond) the forces get bigger and bigger. The
attached file "salida" is the output of this calculation, which I stopped
after five CG interactions as the calculation tends towards non-physical
too short distance, and the forces keep increasing. It seems a
catastrophic diverging behavior.

I have tested that my basis and pseudo reproduce, at the scalar
relativistic level, the reported benchmarks for the PBE functional, so the
pseudo and basis should be OK in principle. But the S-O results make not
physical sense yet...

I have read the instructions in //answers.launchpad.net/siesta/+faq/2779
and I hope to have followed them. I'm not sure if I should still compile
with debug options now that the computational problem has dissapeared.

I could try to perform S-O calculations in the bulk phase, or with smaller
basis sets to see what happens. Right now I have not better ideas. Let me
know if you have any other suggestions.

I'm about to depart with my family on summer vacations, so I will be 15
days out, I'm not in a hurry.

Thx a lot again!

Andrés

On Mon, 30 Jul 2018, Nick Papior wrote:

> Could you try and add this to your arch.make:
>
> state_analysis.o: state_analysis.F
> $(FC) -c $(FFLAGS_DEBUG) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $<
>
> If you still have problems you should carefully follow the instructions
> here:
>
> https://answers.launchpad.net/siesta/+faq/2779
>
> such that we can use the debug options.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1783785
>
> Title:
> spin-polarized and spin-orbit calculations on a gold dimer crash
>
> Status in Siesta:
> New
>
> Bug description:
> Hi,
>
> I am using siesta-4.1-b3 version. I am calculating the gold dimer as a
> simple test of my pseudo and basis set. I have done all the main tests
> using a non-polarized calculation as Au_2 is obviously non-polarized.
> I found no problems at all. Then I wanted to see the effect of S-O
> coupling, but I first tried a spin-polarized calculation just as a
> sanity test. Both calculations (either spin-polarized or spin-orbit)
> proceed apparently well and the SCF convergence is reached. Just after
> that, when I guess the code prints out the final information (energy
> decomposition, dipole moment, etc) the code crashes, both in parallel
> and in serial (in serial I can read "Bus error"; in parallel not much
> information).
>
> I attach both the psf file with the pseudo and the fdf file below. I
> have checked that the mistake is only in the "Spin" order. If you set
> "Spin non-polarized" it works. If you just change this to "Spin
> polarized" it crashes.
>
> Any help will be appreciated. I'm not sure of this is a bug of a
> compiling problem, but the code compiled without any problem. And the
> spin-unpolarized calculation gives almost exactly the same result as
> 4.0.2 ...

[Nick Papior (nickpapior)]

You are using a very low meshcutoff. For SO you should use much higher values (please do a convergence test on this value).

[Andrés Aguado (aaguado)]

Dear Nick,

I had read the manual and I was aware that I am not using appropriate
values of mesh cutoff, electronic temperature, etc, for a really
meaningful spin-orbit calculation. But I certainly would not expect to
obtain forces 3 orders of magnitude off just because of a low cutoff.
I checked that the cutoff is enough at least for the scalar relativistic
calculations.

Now I have progressively increased the cutoff up to near 500 Ry, and
lowered the electronic Temperature till 20 K. The forces are still about
109 eV/Ang. Something weird is going on here...files attached...

According to the literature, the spin-orbit effect on the gold dimer
should decrease the bond length by around 0.1 Ang, so I would expect to
obtain forces around 0.1-0.2 eV/Ang here.

Best wishes,

Andres

On Thu, 2 Aug 2018, Nick Papior wrote:

> You are using a very low meshcutoff. For SO you should use much higher
> values (please do a convergence test on this value).
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1783785
>
> Title:
> spin-polarized and spin-orbit calculations on a gold dimer crash
>
> Status in Siesta:
> New
>
> Bug description:
> Hi,
>
> I am using siesta-4.1-b3 version. I am calculating the gold dimer as a
> simple test of my pseudo and basis set. I have done all the main tests
> using a non-polarized calculation as Au_2 is obviously non-polarized.
> I found no problems at all. Then I wanted to see the effect of S-O
> coupling, but I first tried a spin-polarized calculation just as a
> sanity test. Both calculations (either spin-polarized or spin-orbit)
> proceed apparently well and the SCF convergence is reached. Just after
> that, when I guess the code prints out the final information (energy
> decomposition, dipole moment, etc) the code crashes, both in parallel
> and in serial (in serial I can read "Bus error"; in parallel not much
> information).
>
> I attach both the psf file with the pseudo and the fdf file below. I
> have checked that the mistake is only in the "Spin" order. If you set
> "Spin non-polarized" it works. If you just change this to "Spin
> polarized" it crashes.
>
> Any help will be appreciated. I'm not sure of this is a bug of a
> compiling problem, but the code compiled without any problem. And the
> spin-unpolarized calculation gives almost exactly the same result as
> 4.0.2 version, so it seems OK.
>
> Thanks in advance
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/siesta/+bug/1783785/+subscriptions
>

[Andrés Aguado (aaguado)]

Dear Nick,

I have been trying a few other things, and I have found something.

Before trying the S-O calculations, I first performed scalar relativistic
calculations, on which I optimized the basis set and tested the pseudo.
The basis is quite big as I wanted to reproduce well-converged plane wave
results as a benchmark. In the process, I generated several basis sets of
increasing complexity.

Now I decided to perform S-O calculations on each of those increasingly
more complex basis sets, and I have found that most of these calculations
produce reasonable results. As an example I attach the biggest basis that
produces physically sensible results (see the forces of about 0.1
eV/Ang.).

The only difference between this basis and the most complete one is that I
switched from DZ to TZ also in the "d" channel. Just by adding a third
zeta to the "d" basis functions changes the forces from 0.1 to 100 ev/Ang
and the spin-orbit energy (Eso in the code) from about -0.5 to about -100
eV. Meanwhile, moving from DZ to TZ in the scalar relativistic
calculations just lowered the energy by about 0.01 eV.

In practice, I can just dispense with the TZ "d" basis and it seems it
works. But it is an issue for the developers to understand what exactly is
going on here, because increasing the basis size should be possible also
in S-O calculations.

I am not sure if the error is just an issue of my compiler. I understand
that you optimize SIESTA based on the most modern compiler versions. It
would be nice to know if you also get unphysical results in your machines.

Well, at least this is an advance! Thanks for your help again!

Best wishes,

Andres

[Nick Papior (nickpapior)]

Thanks for your careful analysis and feedback.
I have passed the information on to the developer of S-O.

Thanks!

[Roberto Robles (roberto-robles)]

Dear Andrés and Nick,

I have checked the dimer calculation with the development version of siesta (trunk series). In this version two S-O implementations exist: the onsite (from Jaime Ferrer, the same you are using in the 4.1 series) and the offsite (from Ramón Cuadrado, which we currently prefer since it involves less approximations). The behavior you are describing is reproduced in the onsite implementation, but not in the offsite, where the forces with the "TZ basis" remain below 0.1 eV/angs as expected.

It remains to be seen the origin of the bug, but in the meantime you can check the trunk version. Your fdf file should use the offsite S-O without further modification.

Best,

Roberto

[Andrés Aguado (aaguado)]

Dear Roberto and Nick,

these are great news, as I had no idea that the off-site S-O calculations
were available from the trunk version. I will try to compile this version.
Can it be downloaded as a tgz file as other alpha or beta versions? Thanks
in advance for your help.

Best regards,

Andres Aguado

On Tue, 14 Aug 2018, Roberto Robles wrote:

> Dear Andrés and Nick,
>
> I have checked the dimer calculation with the development version of
> siesta (trunk series). In this version two S-O implementations exist:
> the onsite (from Jaime Ferrer, the same you are using in the 4.1 series)
> and the offsite (from Ramón Cuadrado, which we currently prefer since it
> involves less approximations). The behavior you are describing is
> reproduced in the onsite implementation, but not in the offsite, where
> the forces with the "TZ basis" remain below 0.1 eV/angs as expected.
>
> It remains to be seen the origin of the bug, but in the meantime you can
> check the trunk version. Your fdf file should use the offsite S-O
> without further modification.
>
> Best,
>
> Roberto
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1783785
>
> Title:
> spin-polarized and spin-orbit calculations on a gold dimer crash
>
> Status in Siesta:
> New
>
> Bug description:
> Hi,
>
> I am using siesta-4.1-b3 version. I am calculating the gold dimer as a
> simple test of my pseudo and basis set. I have done all the main tests
> using a non-polarized calculation as Au_2 is obviously non-polarized.
> I found no problems at all. Then I wanted to see the effect of S-O
> coupling, but I first tried a spin-polarized calculation just as a
> sanity test. Both calculations (either spin-polarized or spin-orbit)
> proceed apparently well and the SCF convergence is reached. Just after
> that, when I guess the code prints out the final information (energy
> decomposition, dipole moment, etc) the code crashes, both in parallel
> and in serial (in serial I can read "Bus error"; in parallel not much
> information).
>
> I attach both the psf file with the pseudo and the fdf file below. I
> have checked that the mistake is only in the "Spin" order. If you set
> "Spin non-polarized" it works. If you just change this to "Spin
> polarized" it crashes.
>
> Any help will be appreciated. I'm not sure of this is a bug of a
> compiling problem, but the code compiled without any problem. And the
> spin-unpolarized calculation gives almost exactly the same result as
> 4.0.2 version, so it seems OK.
>
> Thanks in advance
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/siesta/+bug/1783785/+subscriptions
>

[Roberto Robles (roberto-robles)]

Yes, the tarball is available for each revision. For example:

https://bazaar.launchpad.net/~siesta-maint/siesta/trunk/tarball/723

for the 723 one. I have tried 706 in particular, but the last one should give the same results for this particular problem.

Roberto

[Roberto Robles (roberto-robles)]

Dear all,

We have been looking at your input file and you are using a polarized shell of f electrons, meaning you have basis elements up to g character! Removing the f shell gives a correct behavior also with the onsite S-O.

Roberto

[Andrés Aguado (aaguado)]

Dear all,

yes, I expected this might be a problem, and this is why I made tests with
several basis sets. I understand that it is the f-pseudo the one that acts
on the f-polarization function, as there is not g-channel in the pseudos.

However, even if your answer would make sense, I do not think it is
definitive. A basis set with the g-character basis function worked
perfectly well until I included the third zeta function of d-character.
Before that, the polarization function of g-character caused no problems,
so I'm not sure that it is the one to blame.

In any case, the g-function is more important than the TZ d-function in
converging results. According to the review by Pykko on gold, it is well
established that basis functions of g-character are needed in other
localized basis codes. I found the same to be true in SIESTA if I want to
reproduce the benchmark results of plane-wave codes.

I will try to compile the trunk tarball that you mentioned in your
previous email, as I'm also interested in comparing on-site and off-site
results for gold (I believe that in gold S-O effects are important via an
"indirect" mechanism, namely the splitting of the d-orbitals modifies the
amount of s-d hybridization. Maybe the on-site formalism well captures
this effect). Have you tested if off-site calculations are significantly
more expensive than on-site ones?

Thanks again!

Andrés

On Thu, 16 Aug 2018, Roberto Robles wrote:

> Dear all,
>
> We have been looking at your input file and you are using a polarized
> shell of f electrons, meaning you have basis elements up to g character!
> Removing the f shell gives a correct behavior also with the onsite S-O.
>
> Roberto
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1783785
>
> Title:
> spin-polarized and spin-orbit calculations on a gold dimer crash
>
> Status in Siesta:
> New
>
> Bug description:
> Hi,
>
> I am using siesta-4.1-b3 version. I am calculating the gold dimer as a
> simple test of my pseudo and basis set. I have done all the main tests
> using a non-polarized calculation as Au_2 is obviously non-polarized.
> I found no problems at all. Then I wanted to see the effect of S-O
> coupling, but I first tried a spin-polarized calculation just as a
> sanity test. Both calculations (either spin-polarized or spin-orbit)
> proceed apparently well and the SCF convergence is reached. Just after
> that, when I guess the code prints out the final information (energy
> decomposition, dipole moment, etc) the code crashes, both in parallel
> and in serial (in serial I can read "Bus error"; in parallel not much
> information).
>
> I attach both the psf file with the pseudo and the fdf file below. I
> have checked that the mistake is only in the "Spin" order. If you set
> "Spin non-polarized" it works. If you just change this to "Spin
> polarized" it crashes.
>
> Any help will be appreciated. I'm not sure of this is a bug of a
> compiling problem, but the code compiled without any problem. And the
> spin-unpolarized calculation gives almost exactly the same result as
> 4.0.2 version, so it seems...

[Roberto Robles (roberto-robles)]

It is clear that there is a bug for the onsite implementation, I didn't want to imply otherwise. If you need the basis element with g-character then the offsite is the only solution until the bug is fixed.

In any case in our tests the offsite calculations are not more expensive. There is a small penalty in the Hamiltonian setup and in many cases the scf cycle need less iterations. Usually the onsite approximation is good, but we have found significant differences in some cases, mainly topological insulators. It will be interesting to know what happens for gold.

Best,

Roberto

[Andrés Aguado (aaguado)]

Dear Nick and Roberto,

I'm writing just tolet you know that I was able to compile the latest
trunk version. In ourmost modernmachines itcompiled without problems. On
the slightly oldermachines I just had to take care of two OPEN sentences
that use the NEWUNIT flag, apparently not supported by the 11.0 version
ofintel compiler. I solved the issue just by assigning number 99 to the
unit. It's not a big issue, but it may be useful for you to know of this
potential problem...

Well, I tried the off-site calculation on the gold dimer. For a fixed
geometry, the differences in the forces between on-site and off-site
calculations are of the order of 0.02 eV/Ang for the gold dimer, which
will cause at most a 0.02 Ang difference in the equilibrium bond distance,
so a very small difference in this case.

What I did observe is that the off-siteformalism converges much faster! So
even if more matrix elements are calculated, it is much more efficient at
least formy problem. So more accurate and more efficient at the same time
(a rare thing to see). I will continue to use this trunk version for now.
Thank you both for your valuable help. I hope to start productive runs and
not to bother you for some time!

Andres

[Roberto Robles (roberto-robles)]

Great!

Good to see that it converges faster in this case as well.

Roberto

[Nick Papior (nickpapior)]

Great that your problem is resolved.

Regarding the NEWUNIT.

I have opened a new bug-report for this. Thanks! :)

[Andrés Aguado (aaguado)]

Dear Roberto and Nick,

I have found a new problem. It has not to do with the spin-orbit term so I
was not sure if it was better to open a new bug report, so please excuse
me if this was the case.

As you know, I managed to compile the trunk-723 in two of our clusters.
One of them (older) has the ifort 11.0 compiler version, and in those
machines the code compiles and runs perfectly. In the other (newer) we
have:

Compiler version: ifort (IFORT) 15.0.0 20140723

so in principle it should be "better". In this machine the code compiles
without problems but then always give the following error:

rdiag: Error in Cholesky factorisation
Stopping Program from Node: 0

just before starting the SCF cycle. I have tried with many different input
files and the problem occurs for all of them.

As I was surprised at first, I tried to compile the serial version with
the gfortran.make and intel.make files provided with the SIESTA
distribution. With the gfortran option the program runs without error, but
with intel.make the error is there! (so there seems to have no relation
with parallel libraries, etc.). In fact, I understand (correct me if I'm
wrong) that when using the intel.make as arch.make I am not using any
libraries other than those provided with SIESTA (libsiestaLAPACK and
libsiestaBLAS).

I am even more surprised now because I guess that these arch.make example
files are well tested, but there seems to be a problem with the 15.0.0
version of ifort.

I'm attaching an example of calculation (a Zn cluster, but it does not
matter, the problem is general) with the pseudo and the output file so
that you can see the versions of siesta, compiler, etc. and the error. I
can add that exactly the same code with the same input files runs
perfectly in the other machine with the 11.0 compiler. So please, any help
again?

Thanks a lot in advance.

Andres Aguado

[Nick Papior (nickpapior)]

Please open a new bug

[Nick Papior (nickpapior)]

NOTE to dev's:

@Alberto suggests this is an internal problem for the g-shells which is silently handled for polarizations, while it actually crashes for "proper" g-shells.