input file as command line argument?
Moderators: fgoudreault, mcote
Forum rules
Please have a look at ~abinit/doc/config/build-config.ac in the source package for detailed and up-to-date information about the configuration of Abinit 8 builds.
For a video explanation on how to build Abinit 7.x for Linux, please go to: http://www.youtube.com/watch?v=DppLQ-KQA68.
IMPORTANT: when an answer solves your problem, please check the little green V-like button on its upper-right corner to accept it.
Please have a look at ~abinit/doc/config/build-config.ac in the source package for detailed and up-to-date information about the configuration of Abinit 8 builds.
For a video explanation on how to build Abinit 7.x for Linux, please go to: http://www.youtube.com/watch?v=DppLQ-KQA68.
IMPORTANT: when an answer solves your problem, please check the little green V-like button on its upper-right corner to accept it.
-
- Posts: 4
- Joined: Tue Feb 09, 2010 11:31 pm
input file as command line argument?
Hello,
I am trying to run abinit-5.8.3 on a Blue Gene system. The architecture prohibits passing input files via piping ('abinip < input.files' does not work).
Is there a way to pass it as a command line argument? Something like 'abinip -input.files'. If there is not, can you tell me how and where I would have to modify the source code to achieve this?
All the best,
Christian
I am trying to run abinit-5.8.3 on a Blue Gene system. The architecture prohibits passing input files via piping ('abinip < input.files' does not work).
Is there a way to pass it as a command line argument? Something like 'abinip -input.files'. If there is not, can you tell me how and where I would have to modify the source code to achieve this?
All the best,
Christian
Re: input file as command line argument?
Such a mechanism does not exist (yet).
You may however configure Abinit with the --disable-stdin option. Then, at run-time, you'll have to make sure that the "files" file is named ab.files.
You may however configure Abinit with the --disable-stdin option. Then, at run-time, you'll have to make sure that the "files" file is named ab.files.
Yann Pouillon
Simune Atomistics
Donostia-San Sebastián, Spain
Simune Atomistics
Donostia-San Sebastián, Spain
-
- Posts: 4
- Joined: Tue Feb 09, 2010 11:31 pm
Re: input file as command line argument?
Well, that should achieve exactly what I need. Is there an analogue --disable-stdout option to get a default log-file name?
Re: input file as command line argument?
Not to my knowledge. But this could be though about, as it shouldn't be too complicated to implement.
Yann Pouillon
Simune Atomistics
Donostia-San Sebastián, Spain
Simune Atomistics
Donostia-San Sebastián, Spain
Re: input file as command line argument?
Dear Christian,
The --disable-stdin option is actually what you need, because not only it hardcodes the
input file name to "ab.files" , but it also hardcodes the standard output file name to "log".
See the routine 95_drive/iofn1.F90 . The --disable-stdin option activated the CPP READ_FROM_FILE.
Actually, you can further modify this routine to suit your needs !
X
The --disable-stdin option is actually what you need, because not only it hardcodes the
input file name to "ab.files" , but it also hardcodes the standard output file name to "log".
See the routine 95_drive/iofn1.F90 . The --disable-stdin option activated the CPP READ_FROM_FILE.
Actually, you can further modify this routine to suit your needs !
X
-
- Posts: 4
- Joined: Tue Feb 09, 2010 11:31 pm
Re: input file as command line argument?
It worked fine, I can now run abinit on the Blue Gene. But there is still another problem:
The calculation works fine for my case with ecut 20, but this is too low for me. When I raise it I get
memory : analysis of memory needs
================================================================================
Values of the parameters that define the memory need for DATASET 1.
intxc = 0 ionmov = 2 iscf = 7 xclevel = 2
lmnmax = 4 lnmax = 4 mband = 138 mffmem = 1
P mgfft = 180 mkmem = 1 mpssoang= 4 mpw = 139296
mqgrid = 3001 natom = 32 nfft = 2624400 nkpt = 15
nloalg = 4 nspden = 1 nspinor = 1 nsppol = 1
nsym = 2 n1xccc = 0 ntypat = 4 occopt = 1
================================================================================
P This job should need less than 1098.532 Mbytes of memory.
Rough estimation (10% accuracy) of disk space for files :
WF disk file : 303.763 Mbytes ; DEN or POT disk file : 20.025 Mbytes.
================================================================================
Biggest array : f_fftgr(disk), with 320.3633 MBytes.
-P-0000 leave_test : synchronization done...
memana : allocated an array of 320.363 Mbytes, for testing purposes.
memana : allocated 1098.532 Mbytes, for testing purposes.
The job will continue.
DATASET 2 : space group P2 (# 3); Bravais mP (primitive monocl.)
...
some more lines
...
================================================================================
Values of the parameters that define the memory need for DATASET 2.
intxc = 0 ionmov = 2 iscf = 7 xclevel = 2
lmnmax = 4 lnmax = 4 mband = 138 mffmem = 1
P mgfft = 180 mkmem = 1 mpssoang= 4 mpw = 139296
mqgrid = 3001 natom = 32 nfft = 2624400 nkpt = 15
nloalg = 4 nspden = 1 nspinor = 1 nsppol = 1
nsym = 2 n1xccc = 0 ntypat = 4 occopt = 1
================================================================================
memory : COMMENT -
The determination of memory needs at this stage is meaningless,
since getcell = -1 is non-zero, while idtset= 2.
The following numbers are obtained by supposing that acell and rprim
are NOT taken from a previous dataset. You cannot rely on them.
P This job should need less than 1098.532 Mbytes of memory.
Rough estimation (10% accuracy) of disk space for files :
WF disk file : 303.763 Mbytes ; DEN or POT disk file : 20.025 Mbytes.
================================================================================
Biggest array : f_fftgr(disk), with 320.3633 MBytes.
-P-0000 leave_test : synchronization done...
-P-0000 leave_test : exiting...
Now what we see here is the following: Memory consumption for dataset 1 is checked, arrays are allocated and the job continues. Then it comes to the same point for dataset 2 and the memory test seems to fail. And the biggest array is estimated to be 320 MB, this is far below the memory of the system (it has 4 GB per core I believe). What could be the reason for this behaviour?
The calculation works fine for my case with ecut 20, but this is too low for me. When I raise it I get
memory : analysis of memory needs
================================================================================
Values of the parameters that define the memory need for DATASET 1.
intxc = 0 ionmov = 2 iscf = 7 xclevel = 2
lmnmax = 4 lnmax = 4 mband = 138 mffmem = 1
P mgfft = 180 mkmem = 1 mpssoang= 4 mpw = 139296
mqgrid = 3001 natom = 32 nfft = 2624400 nkpt = 15
nloalg = 4 nspden = 1 nspinor = 1 nsppol = 1
nsym = 2 n1xccc = 0 ntypat = 4 occopt = 1
================================================================================
P This job should need less than 1098.532 Mbytes of memory.
Rough estimation (10% accuracy) of disk space for files :
WF disk file : 303.763 Mbytes ; DEN or POT disk file : 20.025 Mbytes.
================================================================================
Biggest array : f_fftgr(disk), with 320.3633 MBytes.
-P-0000 leave_test : synchronization done...
memana : allocated an array of 320.363 Mbytes, for testing purposes.
memana : allocated 1098.532 Mbytes, for testing purposes.
The job will continue.
DATASET 2 : space group P2 (# 3); Bravais mP (primitive monocl.)
...
some more lines
...
================================================================================
Values of the parameters that define the memory need for DATASET 2.
intxc = 0 ionmov = 2 iscf = 7 xclevel = 2
lmnmax = 4 lnmax = 4 mband = 138 mffmem = 1
P mgfft = 180 mkmem = 1 mpssoang= 4 mpw = 139296
mqgrid = 3001 natom = 32 nfft = 2624400 nkpt = 15
nloalg = 4 nspden = 1 nspinor = 1 nsppol = 1
nsym = 2 n1xccc = 0 ntypat = 4 occopt = 1
================================================================================
memory : COMMENT -
The determination of memory needs at this stage is meaningless,
since getcell = -1 is non-zero, while idtset= 2.
The following numbers are obtained by supposing that acell and rprim
are NOT taken from a previous dataset. You cannot rely on them.
P This job should need less than 1098.532 Mbytes of memory.
Rough estimation (10% accuracy) of disk space for files :
WF disk file : 303.763 Mbytes ; DEN or POT disk file : 20.025 Mbytes.
================================================================================
Biggest array : f_fftgr(disk), with 320.3633 MBytes.
-P-0000 leave_test : synchronization done...
-P-0000 leave_test : exiting...
Now what we see here is the following: Memory consumption for dataset 1 is checked, arrays are allocated and the job continues. Then it comes to the same point for dataset 2 and the memory test seems to fail. And the biggest array is estimated to be 320 MB, this is far below the memory of the system (it has 4 GB per core I believe). What could be the reason for this behaviour?