Skip to content

Error when reading real array value #236

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
handrake0724 opened this issue Nov 18, 2016 · 9 comments
Closed

Error when reading real array value #236

handrake0724 opened this issue Nov 18, 2016 · 9 comments

Comments

@handrake0724
Copy link

handrake0724 commented Nov 18, 2016

Let a jsong file as :

{
  "x0" : [1.0, 2.0]
}

the code is as follows:

use json_module
type(json_file) :: json
logical :: found
real, dimension(:), allocatable :: rArray

call json%get("x0", rArray, found)

I got the following error

There is no matching specific subroutine for this type bound generic subroutine call. [GET]

FYI, my compile environment is visual studio 2015 + intel compiler

@jacobwilliams
Copy link
Owner

Currently, JSON-Fortran only supports real64 values (i.e., "double precision"). The real kind is exported by the library as json_RK, so you could declare your variable:

real(json_rk), dimension(:), allocatable :: rArray

and it should work.

@handrake0724
Copy link
Author

Thanks for the comment.

@zbeekman
Copy link
Contributor

@handrake0724 if this resolves your problem, please close the issue.

@jacobwilliams I wonder what it would take to support single precision as well. All the get methods seem like they could be implemented with simple wrappers that call the double precision version and then convert to single before returning. There may be some complications with IO, i.e. matching IO precision to that used to put the value in the first place. Another potential difficulty with my proposed approach may be when single precision puts are followed by gets, depending on the specifics of the compilers type conversion/rounding. I don't know if the standard says anything about this.

@milancurcic
Copy link

@zbeekman @jacobwilliams FWIW it is at least straightforward to allow a single precision (instead of double precision) build of json-fortran by doing:

    use,intrinsic :: iso_fortran_env, only: real32,real64,int32,logical_kinds
...
#ifdef REAL32
    integer,parameter,public :: RK = real32  !! Default real kind [4 bytes]
#else
    integer,parameter,public :: RK = real64  !! Default real kind [8 bytes]
#endif

in src/json_kinds.F90. This is what I do in my local copy of json-fortran because my top project needed to be able to work with single precision as well. So far it works as expected and did not notice any loss of precision. Since the top project needed exclusively single or double precision, but not both at the same time, this approach was satisfactory for me.

@zbeekman
Copy link
Contributor

Yes adding such a build time option is trivial and should probably be
included in the mean time.
On Fri, Nov 18, 2016 at 10:53 AM Milan Curcic notifications@github.com
wrote:

@zbeekman https://github.com/zbeekman @jacobwilliams
https://github.com/jacobwilliams FWIW it is at least straightforward to
allow a single precision (instead of double precision) build of
json-fortran by doing:

use,intrinsic :: iso_fortran_env, only: real32,real64,int32,logical_kinds

...
#ifdef REAL32
integer,parameter,public :: RK = real32 !! Default real kind [4 bytes]
#else
integer,parameter,public :: RK = real64 !! Default real kind [8 bytes]
#endif

in src/json_kinds.F90. This is what I do in my local copy of json-fortran
because my top project needed to be able to work with single precision as
well. So far it works as expected and did not notice any loss of precision.
Since the top project needed exclusively single or double precision, but
not both at the same time, this approach was satisfactory for me.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#236 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAREPOxaPel0PQWHGJd4ydP3G3bJe1Yxks5q_cnogaJpZM4K2NBn
.

@jacobwilliams
Copy link
Owner

See also #229. I just haven't had time to review it. My preference would be to use the @zbeekman approach, where they are stored as real64 internally, and then there are just real32 wrappers that do the conversion. The details would have to be worked out as indicated.

@milancurcic Yes, I like this. I could add this to the code. Then you could use it as-is without having to modify it.

What about real128? Should that also be a possibility?

@zbeekman
Copy link
Contributor

We can use cmake to query for fortran real and integer kinds. It may make
sense to also allow big integers. On todays HPC systems this is
increasingly relevant as unstructured simulations can be run meshes large
enough to require usage of big integers (FUN3D for example)

On Fri, Nov 18, 2016 at 10:59 AM Jacob Williams notifications@github.com
wrote:

See also #229 #229. I
just haven't had time to review it. My preference would be to use the
@zbeekman https://github.com/zbeekman approach, where they are stored as
real64 internally, and then there are just real32 wrappers that do the
conversion. The details would have to be worked out as indicated.

@milancurcic https://github.com/milancurcic Yes, I like this. I could add
this to the code. Then you could use it as-is without having to modify it.

What about real128? Should that also be a possibility?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#236 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAREPH1Hp_O1Wc57_nbII7EeBfW7Hx19ks5q_ctygaJpZM4K2NBn
.

@jacobwilliams
Copy link
Owner

So, for completeness, something like this:

#ifdef REAL32
    integer,parameter,public :: RK = real32   !! Default real kind [4 bytes]
#elseif REAL64
    integer,parameter,public :: RK = real64   !! Default real kind [8 bytes]
#elseif REAL128
    integer,parameter,public :: RK = real128  !! Default real kind [16 bytes]
#else
    integer,parameter,public :: RK = real64   !! Default real kind if not specified [8 bytes]
#endif

#ifdef INT8
    integer,parameter,public :: IK = int8      !! Default integer kind [1 byte]
#elseif INT16
    integer,parameter,public :: IK = int16     !! Default integer kind [2 bytes]
#elseif INT32
    integer,parameter,public :: IK = int32     !! Default integer kind [4 bytes]
#elseif INT64
    integer,parameter,public :: IK = int64     !! Default integer kind [8 bytes]
#else
    integer,parameter,public :: IK = int32     !! Default integer kind if not specified [4 bytes]
#endif

@zbeekman
Copy link
Contributor

Yes, and I'll insert come compiler introspection code into the cmake build
system to ensure that each requested kind type exists. If not, on the cmake
end, we can print an error/warning if a kind is requested at compile time
that isn't present.

On Fri, Nov 18, 2016 at 11:15 AM Jacob Williams notifications@github.com
wrote:

So, for completeness, something like this:

#ifdef REAL32
integer,parameter,public :: RK = real32 !! Default real kind [4 bytes]

#elseif REAL64

integer,parameter,public :: RK = real64 !! Default real kind [8 bytes]

#elseif REAL128
integer,parameter,public :: RK = real128 !! Default real kind [16 bytes]
#else
integer,parameter,public :: RK = real64 !! Default real kind if not specified [8 bytes]
#endif

#ifdef INT8
integer,parameter,public :: IK = int8 !! Default integer kind [1 byte]
#elseif INT16
integer,parameter,public :: IK = int16 !! Default integer kind [2 bytes]
#elseif INT32
integer,parameter,public :: IK = int32 !! Default integer kind [4 bytes]
#elseif INT64
integer,parameter,public :: IK = int64 !! Default integer kind [8 bytes]
#else
integer,parameter,public :: IK = int32 !! Default integer kind if not specified [4 bytes]
#endif


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#236 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAREPIH5_OT_pHTMyNHjZZYqlEQDczwnks5q_c8UgaJpZM4K2NBn
.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants