I am working on an initial build of VASP 5.3.3. All files compiled and linked with the PGI compiler, and I've successfully (it seems) made an executable. When I run a simple problem, however, I get the following error.
vasp.5.3.3 18Dez12 (build Mar 9 2013 12:13:51) complex
POSCAR found : 1 types and 2 ions
PGFIO-F-207/OPEN/unit=1/file is already connected to another unit.
File name = INCAR
In source file charge.f, at line number 1365[/color]
I am looking for ideas of how to address this issue.
Thanks much
Problem in charge.f at line 1365?
Moderators: Global Moderator, Moderator
-
jn_petersen
- Newbie
- Posts: 2
- Joined: Mon Mar 11, 2013 3:41 am
- License Nr.: 5-1064
Problem in charge.f at line 1365?
Last edited by jn_petersen on Fri Apr 05, 2013 3:43 am, edited 1 time in total.
-
lilianabraescu
- Newbie
- Posts: 1
- Joined: Thu Jul 11, 2013 7:06 pm
Problem in charge.f at line 1365?
Hi,
I am working on VASP 5.3.3. Files were compiled using PGI 13.6 for Ubuntu 12.04.
When I run a problem, I have the same error described above:
"PGFIO-F-207/OPEN/unit=1/file is already connected to another unit."
Any help would be highly appreciated.
Liliana
I am working on VASP 5.3.3. Files were compiled using PGI 13.6 for Ubuntu 12.04.
When I run a problem, I have the same error described above:
"PGFIO-F-207/OPEN/unit=1/file is already connected to another unit."
Any help would be highly appreciated.
Liliana
Last edited by lilianabraescu on Fri Jul 12, 2013 11:04 pm, edited 1 time in total.
-
cchang
- Newbie
- Posts: 12
- Joined: Mon Jan 28, 2013 11:22 pm
Problem in charge.f at line 1365?
Just ran into this problem as well. Posting my particular tracking-down-and-solution process, in case it helps.
* Fortran standard forbids having two different units attached to the same open file simultaneously, hence the error.
* Failed OPEN in charge.F within subroutine GGA_COMPAT_MODE(IU5, ...).
* main.F, ~line 526 calls this routine. Line 340 defines IO%IU5 as 7; however, GGA_COMPAT_MODE gets called with value 1.
* Discovered that previous call to READER changed the value.
* Tracked the value change to call to RDATAB around line 1280 in reader.F.
* Discovered that RDATAB in the vasp support library has a single test to reassign the IU argument (IU5, in this call) if the incoming argument is <0 or >99. Perplexed, as it should be 7.
* When rebuilding with write statement, discovered ***I ACCIDENTALLY BUILT -i8***, whereas main VASP was 32-bit int. So, IU5 from VASP was being interpreted as garbage, and getting re-assigned to the next free unit (= unit 1).
* Took out -i8 for the library build, problem solved. Moral, make sure my integer widths are consistent between the libdmy.a build and the main VASP executable builds!
* Fortran standard forbids having two different units attached to the same open file simultaneously, hence the error.
* Failed OPEN in charge.F within subroutine GGA_COMPAT_MODE(IU5, ...).
* main.F, ~line 526 calls this routine. Line 340 defines IO%IU5 as 7; however, GGA_COMPAT_MODE gets called with value 1.
* Discovered that previous call to READER changed the value.
* Tracked the value change to call to RDATAB around line 1280 in reader.F.
* Discovered that RDATAB in the vasp support library has a single test to reassign the IU argument (IU5, in this call) if the incoming argument is <0 or >99. Perplexed, as it should be 7.
* When rebuilding with write statement, discovered ***I ACCIDENTALLY BUILT -i8***, whereas main VASP was 32-bit int. So, IU5 from VASP was being interpreted as garbage, and getting re-assigned to the next free unit (= unit 1).
* Took out -i8 for the library build, problem solved. Moral, make sure my integer widths are consistent between the libdmy.a build and the main VASP executable builds!
Last edited by cchang on Mon Mar 31, 2014 9:27 pm, edited 1 time in total.