Hi,
No, said line shouldn't be the cause of anything... :( And fdf inputs
shouldn't generate a seg-fault.
Another try for debugging would be to add full traceback calls:
Intel:
FFLAGS = -O0 -g -check bounds -traceback
Which should be more informative.
Also, Intel is notorious for using the stack, do you have ulimit -s
unlimited?
As a last resort, try with Gnu compilers. And if this doesn't work, then
please provide all inputs etc.
Den man. 25. mar. 2019 kl. 22.01 skrev Day, Zacharie <d...@email.gwu.edu>:
>
> Deleting the TBTGF files did not solve the problem. So, my two guesses now
> are that there is an issue with the compilation of TBTrans (but it's
> compiled with stock Intel compiler, so I imagine someone else would have
> run into this) or there is an error in the input code. Would an error in
> the input (as in, the FDF files) be able to cause such a segfault?
>
> On Sat, Mar 9, 2019 at 4:00 PM Nick Papior <nickpap...@gmail.com> wrote:
>
>> Could you please delete all TBTGF* files, and rerun the calculation?
>>
>> Alternatively, see if increasing the eta value helps.
>>
>> Den fre. 8. mar. 2019 kl. 22.02 skrev Day, Zacharie <d...@email.gwu.edu>:
>>
>>> Hello,
>>>
>>> A user on my cluster is trying to process something with Siesta 4.0.2
>>> TBTrans_rep. The process works up until this output:
>>>
>>> ==============================================================
>>> Projection Region: atoms : [ 183; 244]
>>> Projection Region: states: [ 1639; 2172] Tot: 534
>>> Reading GF file, with title:
>>> /home/rao/SIESTA/ODT/test/tbt/ODT-Au-1K.TBTGFL
>>> Title: 'Generated GF file'
>>>
>>> Reading GF file, with title:
>>> /home/rao/SIESTA/ODT/test/tbt/ODT-Au-1K.TBTGFR
>>> Title: 'Generated GF file'
>>>
>>> # k-point: 1
>>> # k = -0.026388, 0.026388, 0.000000, w= 0.222222
>>> # kb = -0.166667, 0.166667, 0.000000, w= 0.222222
>>> After this point, the program terminates after a short period with
>>> "Program received signal SIGSEGV, Segmentation fault." Furthermore, the
>>> issue occurs regardless of whether it's run alone or with MPI.
>>> GDB gives this:
>>>
>>> 0x00000000005071fd in transmission (usebulk=@0xffffffff,
>>> nou=@0x21600000f3c, hk=..., sk=...,
>>> nod=@0x66700000216, nol=@0x6c000000666, sfel=..., nor=@0x6c0,
>>> sfer=...,
>>> zenergy=@0xbfb2c0b552857fde, gf=..., gfrgf=..., tottrans=@0x0,
>>> tt=..., ierr=@0x0)
>>> at transmission.f90:94
>>> 94 transmission.f90: No such file or directory.
>>> in transmission.f90
>>> I looked at transmission.f90 but I do not understand Siesta's code well
>>> enough to see any issues with line 94. Siesta is compiled on this cluster
>>> as follows:
>>>
>>> Siesta Version : v4.0.2
>>> Architecture : intel-mkl
>>> Compiler version: ifort (IFORT) 13.0.1 20121010
>>> Compiler flags : mpiifort -g -O0
>>> PP flags : -DFC_HAVE_FLUSH -DFC_HAVE_ABORT -DMPI
>>>
>>> I added the -O0 when I came across some mails suggesting that Intel's
>>> optimizations may be the culprit, however it would seem that that is not
>>> the case here. As I am entirely stuck on this issue, I would appreciate any
>>> assistance.
>>>
>>> --
>>> Zacharie Day
>>> Systems Analyst
>>> The George Washington University, SEAS Computing Facility
>>>
>>
>>
>> --
>> Kind regards Nick
>>
>
>
> --
> Zacharie Day
> Systems analyst
> The George Washington University, SEAS Computing Facility
> (202) 994-3963
>
>
--
Kind regards Nick
