andreww / fox Goto Github PK

problem description:

Im trying to extract the text between the name tags. The text data seems to get mangled if bracket characters appear in the text. Im not aware that these characters are illegal?

Example input file:

<?xml version="1.0" encoding="ISO-8859-1"?>

<name>
[_tmp]:=somecommand(data, 0, 1)
</name>

output on screen:

[_tmp]:]=]s]o]m]e]c]o]m]m]a]n]d](]d]a]t]a],] ]0],] ]1])]
]      

source code:

 program dom
 use FoX_dom
 implicit none

 integer :: i
 type(Node), pointer :: doc, name
 type(NodeList), pointer :: nameList
 character(200) :: name_text

 doc => parseFile("test.xml")

 nameList => getElementsByTagname(doc, "name")

 do i = 0, getLength(nameList) - 1
   name_text = ''
   name => item(nameList,i)

   !call extractDataContent(name, name_text)
   name_text = getTextContent(name)

   print *, name_text
 enddo

 call destroy(doc)
 end program dom

Three of the 'abnormal example' URIs given in rfc 2396 are processed incorrectly leading to one test failing in /utils. These is a test for this (and it fails).

Dear all,

I am trying to install Fox on Ubuntu 18.04 but I am faced with this error:

mkdir -p objs/lib objs/finclude
(cd fsys; make VPATH=/fsys)
make[1]: Entering directory '/home/mkashkouli/Desktop/EMTF FCU/fox-master/fsys'
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_abort_flush.F90
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_array_str.F90
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_realtypes.f90
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_format.F90
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_parse_input.F90
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_count_parse_input.F90
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_string.F90
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_string_list.F90
gfortran -c -g -O2  -DPACKAGE_NAME=\"FoX\" -DPACKAGE_TARNAME=\"fox\" -DPACKAGE_VERSION=\"4.1.2\" -DPACKAGE_STRING=\"FoX\ 4.1.2\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DFC_HAVE_FLUSH=1 -DFC_HAVE_ABORT=1 -DFC_EOR_LF=1    fox_m_fsys_varstr.F90
  ==> Creating libFoX_fsys.a with fox_m_fsys_abort_flush.o fox_m_fsys_array_str.o fox_m_fsys_format.o fox_m_fsys_parse_input.o fox_m_fsys_count_parse_input.o fox_m_fsys_string.o fox_m_fsys_string_list.o fox_m_fsys_realtypes.o fox_m_fsys_varstr.o
ar: `u' modifier ignored since `D' is the default (see `U')
cp -p libFoX_fsys.a /home/mkashkouli/Desktop/EMTF FCU/fox-master/objs/lib 
cp: target 'FCU/fox-master/objs/lib' is not a directory
makefile:24: recipe for target 'install' failed
make[1]: *** [install] Error 1
make[1]: Leaving directory '/home/mkashkouli/Desktop/EMTF FCU/fox-master/fsys'
Makefile:130: recipe for target 'fsys_lib' failed
make: *** [fsys_lib] Error 2

Also, my configure is:

checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gfortran... gfortran
checking whether the Fortran compiler works... yes
checking for Fortran compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran compiler... yes
checking whether gfortran accepts -g... yes
checking for ranlib... ranlib
configure: gfortran seems to be a Gfortran compiler
checking for kind number produced by kind(1.0)... 4
checking for kind number produced by kind(1.0d0)... 8
checking for kind number produced by selected_real_kind(6,34)... 4
checking for kind number produced by selected_real_kind(15,300)... 8
checking how to compile a call to FLUSH... default
checking how to compile a call to ABORT... default
checking for EOR character used by gfortran... LF
checking for ASSOCIATED in restricted expression bug... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking Fortran 90 module inclusion flag... -I
checking Fortran 90 module extension... mod
configure: creating ./config.status
config.status: creating arch.make
config.status: creating FoX-config

How can I fix this issue?

Regards,
Mohammad

I am trying to use the FoX library to parse large xml files with data (~2MB). The methods (sax, dom) take forever to parse some files that MATLAB/C/Python/... can parse in a couple of seconds.

Is this a known issue with the library or am I doing something wrong?

We need tests for windows style file URIs - and a fix for the single currently failing test case

I should really make a cone-producing function and use that to test these output subroutines.

At present the CML CompChem convention does not say how to write out a complex number (or an array of complex numbers). FoX mostly follows the CMLComp convention and has a way of writing such numbers (with the fpx:complex as the datatype). However, we now have a way of telling FoX to try and produce CompChem and are debating how to represent complex numbers in this case. Once we know how to do this we should do so on either the NWchem branch or on master if that has been merged.

Dear all,

I encountered a problem when compiling Quantum Esspresso (version 6.5). Quantum Esspresso (QE) is a quantum chemistry calculation package which includes the FoX source code. Blow is the error message:
...
/usr/bin/ld: /ddk/qe//FoX/lib/libFoX_fsys.a(fox_m_fsys_string.o): relocation R_X86_64_32 against .rodata' can not be used when making a PIE object; recompile with -fPIC /usr/bin/ld: /ddk/qe//FoX/lib/libFoX_fsys.a(fox_m_fsys_string_list.o): relocation R_X86_64_32 against .rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: /ddk/qe//FoX/lib/libFoX_fsys.a(fox_m_fsys_varstr.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:256: pw.x] Error 1
make[2]: Leaving directory '/ddk/qe/PW/src'
make[1]: *** [Makefile:9: pw] Error 1
make[1]: Leaving directory '/ddk/qe/PW'
make: *** [Makefile:74: pw] Error 1

I googled a lot and tried to re-configure and make the QE with various options such as the following commands, but still got the same errors.
make distclean
./configure CFLAGS=-fPIC CPPFLAGS=-fPIC FFLAGS=-fPIC
make all
It seems that the FoX package has to be compiled with -fPIC flag. My OS is CentOS 8 (64 bit, Intel CPU). Could someone tell me how to resolve this problem? Thanks a lot in advance.

The main FoX website has moved. There are a handful of links to it from the (portable) html generated from the DoX directory. These need updating.

Tests for the new SAX error reporting cases.

The final 'touch /.f90 /.F90' command in the configure script is included directly from configure.ac in order to:
dnl and to stop over-eager makes trying to recreate f90 files
dnl when m4 is not gnu m4 ..
This fails if configure is run from outside the main FoX directory (e.g. for Siesta when VPATH is used).

I am playing around with xml string and with attribute Name which contains some defined HTML string

<Student Name="&#x00C9;mily" />

and FoX gives from extractDataAttribute() string "&mily", and not the original one. I would rather be happy with "Émily" string in order to have a chance to translate it manually to "Émily" ...

Hi,

I have been trying to run QUIP pair_style in lammps. My main aim is to use Tangney-Scandolo potential, but I have been getting various errors and have not been able to successfully run any simulation.

I am using potential file that is located in QUIP/share/Parameters/ip.parms.TS.xml. When I take the file as is I get this error from LAMMPS:

ERROR(FoX)
Cannot open second root element (Possibly near line=0 col=949)

After this I have tried to modify the file and left only the first section of it:

<TS_params label="ewald_GGA" betapol="0.75" cutoff="20.0 22.0 18.0 0.0" n_types="2" yuksmoothlength="0.0" pred_order="2" 
  maxipol="60" tolpol="1e-10" yukalpha="0.0" tewald="T" a_ew="1e-06" iesr="-1 -1 -1">

  <per_type_data atomic_num="8" pol="8.89378" z="-1.38257" type="1" />
  <per_type_data atomic_num="14" pol="0.0" z="2.76514" type="2" />

  <per_pair_data C_pol="0.0" atnum_j="8" atnum_i="8" D_ms="0.00024748" gamma_ms="12.07092" B_pol="0.0" R_ms="7.17005" /> 
  <per_pair_data C_pol="-1.50435" atnum_j="8" atnum_i="14" D_ms="0.0019033" gamma_ms="11.1523" B_pol="2.02989" R_ms="4.6371" />
  <per_pair_data C_pol="0.0" atnum_j="14" atnum_i="14" D_ms="-0.0020846" gamma_ms="10.45517" B_pol="0.0" R_ms="5.75038" />

</TS_params>

After this modification the xml is read OK but I get new error:

SYSTEM ABORT: proc=0 Potential_read_params_xml: could not initialise potential from xml_label. param_str=<TS_params label-
="ewald_GGA" betapol="0.75" cutoff="20.0 22.0 18.0 0.0" n_types="2" yuksmoothlength="0.0" pred_order-
="2"   maxipol="60" tolpol="1e-10" yukalpha="0.0" tewald="T" a_ew="1e-06" iesr="-1 -1 -1">   <per_ty-
pe_data atomic_num="8" pol="8.89378" z="-1.38257" type="1" />   <per_type_data atomic_num="14" pol="-
0.0" z="2.76514" type="2" />   <per_pair_data C_pol="0.0" atnum_j="8" atnum_i="8" D_ms="0.00024748"
gamma_ms="12.07092" B_pol="0.0" R_ms="7.17005" />   <per_pair_data C_pol="-1.50435" atnum_j="8" atnu-
m_i="14" D_ms="0.0019033" gamma_ms="11.1523" B_pol="2.02989" R_ms="4.6371" />   <per_pair_data C_pol-
="0.0" atnum_j="14" atnum_i="14" D_ms="-0.0020846" gamma_ms="10.45517" B_pol="0.0" R_ms="5.75038" />
</TS_params>
--------------------------------------------------------------------------

The relevant part of LAMMPS input script:

pair_style	quip
pair_coeff * * ip.parms.TS.xml "TS_params xml_label=ewald_GGA" 8 14

I have no idea how to fix this and would appreciate any help.

The current version of autoconf (2.65) does not seem to like our local version of fortran.m4 (which adds pre-processed fortran as a language - this never made it upstream). Fails with:

autoconf
configure.ac:19: error: AC_LANG_CONFTEST: unknown language: Preprocessed Fortran
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2557: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2573: AC_COMPILE_IFELSE is expanded from...
aclocal.m4:3198: _AC_FPP_FIXEDFORM_F is expanded from...
aclocal.m4:4291: _AC_PROG_FC_CPP is expanded from...
aclocal.m4:4634: AC_PROG_FPP is expanded from...
configure.ac:19: the top level

... Looks like the way languages are defined has changed. (Autoconf 2.59 (the older version on debian sid) mostly works, but this pre-dates the mkdir -p macro so this fails for another reason.)

In an ideal world we would run CI tests with other compilers, and ifort would be the obvious one (as that's still well used). I should look at that.

One problem will be that new(ish) iforts add "abort:" at the end of tests which abort. We could work around this for gortran by doing BUILD_SCRIPT="FC='gfortran -fno-backtrace' ./configure && ... (see d2ad441). The ifort version, BUILD_SCRIPT="FC='ifort -notraceback' ./configure && leaves the "abort:" in place. At least for 17.0.1 on ARC3.

It looks like the first bullet point in the LICENSE file should not be a bullet point. Is this why github does not pick up the license?

Hi,

I had to add file m_wcml_inputdec.F90 to your file .vfproj in order to compile Fox using Visual Studio. With this change the compilation was Ok.

See #36 - does configure work correctly for Call FLUSH_ on IBM's XLF compiler or is there a difference between how the compiler is called for CMake and make?

We need to add #ifdef dummylib around the bodies of most of the wkml procedures, rename files from .f90 to .F90 and check the makefile handle this case. Intent out variables need to be handled as does color_t and xf.

The NAG compiler warns that some of the procedure names (wrapped up in generic interfaces) are too long. The limit in Fortran 95 is 31 characters but this does not seem to trip up any compilers in practice.

Add something in the documentation re. use of FoX on parallel applications (e.g. MPI) referencing Pietro Delugas's changes at #49

On the NWchem branch we have new subroutines for orbitals. This code should be reviewed, test cases and documentation written, and the code merged into master.

I am trying to make use of sax libraries in the oorb program https://github.com/oorb/oorb but I am strugling with it. After linking the libraries in the make file, and only adding the use statement to the program USE FoX_sax (not any functions or subroutines) While compiling, I am getting the next error, which repets itself over 20 times.

../main/oorb.f90:31:12:

PROGRAM oorb
1
Error: Fortran 2003: Procedure pointer at (1)

Adding the USE statement to the only subroutine which use FoX functions reports me the same error, just changing the file where it pops up.

Maybe it is some problem with the linking of the library (which I will have to further investigate). It is difficult to explain the whole situation through here because it involve a quite complex Makefile, but I wanted to make sure if somebody faced this same issue before spending more time on it.

Thank you very much!

Document:

• compchem argument to startCML
• input dec stuff

Test:

• More input dec stuff

It is reported that:

$ ./configure FC=/usr/local/bin/gfortran --prefix=/usr/local/FoX
$ make
$ sudo make install

if I then run:

$ /usr/local/FoX/bin/FoX-config --libs

I get:

/tmp/FoX-4.1.2/objs/lib/libFoX_wkml.a /tmp/FoX-4.1.2/objs/lib/libFoX_dom.a
/tmp/FoX-4.1.2/objs/lib/libFoX_sax.a /tmp/FoX-4.1.2/objs/lib/libFoX_wcml.a
/tmp/FoX-4.1.2/objs/lib/libFoX_wxml.a /tmp/FoX-4.1.2/objs/lib/libFoX_common.a
/tmp/FoX-4.1.2/objs/lib/libFoX_utils.a /tmp/FoX-4.1.2/objs/lib/libFoX_fsys.a

which is wrong - should be /use/local/FoX in that path.

Having merged @MatthewHambley's changes to enable compilation with the Cray Fortran compiler, it would seem sensible to have the continuous integration system test the build with this and other compilers as further changes are made.

c.f. #54 for issues in this area with respect to the intel compiler.

Hi
I found same version codes (4.1.2) in this github and the link below
http://homepages.see.leeds.ac.uk/~earawa/FoX/source/

and I also found the codes named same version are different in some f90 files.
Maybe you modified some parts, which one is more recent and compact?
In addition, FoX from the link even does not have test codes about DOM api and
the test codes about SAX api did not work because of "len(attributes)" in m_handler

I'll be waiting for your reply.
Thanks and sorry for my poor English.

We have lots of tests. It would be good to run these as we change the code.

The heading argument to kmlCreatePointStyle accepts integer values between -180 and 180 degrees. This is checked in the code and an error is raised for values outside this range. There are tests to check this works. However, google's kml spec page says the value should be between 0 and 360. We should either only accept numbers in that range, or add 360 to negative values to produce the correct output without breaking the API.

Add some documentation for building on Windows - and put the visual studio project file in a sensible place.

This (on the NWchem branch and used for orbitals) needs documentation and tests.

Report of errors from make check with gfortran 4.8.0... Part of my reply to Francisco: I think the errors you see when doing "make check" with gfortran 4.8.0 are because new gfortrans will build executables such that they dump a backtrace if they abort (this had to be enabled with a command line switch for earlier versions). FoX will trigger an abort by default in response to things like trying to write a malformed XML document and this is tested in the test suite. The presence of a backtrace is confusing the test harness. You can work around this by adding -fno-backtrace to the FFLAGS line in arch.make after running configure and before running make or make check. We should probably make the configure script test for the presence of a backtrace in this case and turn it off (by adding the flag). That's a non-trivial little project in itself though.

Gen-Tao had several examples of the use of the wkml interface features. These should be updated for API changes and checked then merged into the /examples directory. We should probably have a way to check the output of the resulting executables when make check is run.

It's worth adding information on building with CMake to the documentation and maybe the quick start information. The basic command (from the command line) is:

mkdir build_master/ && cd build_master/ && cmake ../ && make -j

We should also list information on how to select parts of FoX to compile - as outlined by @victorsndvg in #34

(a) All versions of ifort 11.1 fail to compile the sax module with an internal compiler error.
(b) wxml/wcml will compile, but most tests fail with an error from the runtime complaining about deallocation of unallocated data.

In 4.1.2, you have the following code on line 1515 of m_sax_parser.f90:
if (associated(tempString2)) deallocate(tempString2)

However, tempString2 is nowhere initialized to null. This results in the program crashing whenever you call saxParse twice within the same run. (In my case, I was calling it via parseFile.)

Building with --enable-dummy results in warnings like this:

In file m_wkml_color.F90:159

  subroutine kmlSetCustomColor(myCI, colorhex)
                               1
Warning (158): INTENT(OUT) variable 'myci' at (1) is never set
In file m_wkml_color.F90:180

  function kmlGetColor_index(i) result(c)
           1
Warning (139): Value of function 'kmlgetcolor_index' at (1) is never set
In file m_wkml_color.F90:195

  function kmlGetColor_byName(name) result(c)
           1
Warning (139): Value of function 'kmlgetcolor_byname' at (1) is never set

and like this:

In file fox_m_fsys_parse_input.F90:43

  subroutine scalartostring(s, data, separator, csv, num, iostat)
                                                          1
Warning (158): INTENT(OUT) variable 'iostat' at (1) is never set
In file fox_m_fsys_parse_input.F90:194

  subroutine scalartological(s, data, num, iostat)
                                      1  
Warning (158): INTENT(OUT) variable 'num' at (1) is never set
In file fox_m_fsys_parse_input.F90:194

  subroutine scalartological(s, data, num, iostat)
                                           1
Warning (158): INTENT(OUT) variable 'iostat' at (1) is never set

Should we fix these? I'm minded not to as this way we can use e.g. valigrand to find errors where the user application is dependent on FoX being compiled without --enable-dummy.

Elena Breitmoser reports warnings with the Cray Fortran 8.0.4 compiler with FoX 4.1.2:

     s2(m:) = s(s_i:k)

ftn-7212 crayftn: WARNING SCALARTOSTRING, File =
fox_m_fsys_parse_input.F90, Line = 92
Variable "m" is used before it is defined.

     s2(m:) = s(s_i:k)

ftn-7212 crayftn: WARNING ARRAYTOSTRING, File =
fox_m_fsys_parse_input.F90, Line = 802
Variable "m" is used before it is defined.

     s2(m:) = s(s_i:k)

ftn-7212 crayftn: WARNING MATRIXTOSTRING, File =
fox_m_fsys_parse_input.F90, Line = 955
Variable "m" is used before it is defined.

     s2(m:) = s(s_i:k)

ftn-7212 crayftn: WARNING COUNTSTRING, File =
fox_m_fsys_count_parse_input.F90, Line = 74
Variable "m" is used before it is defined.

subroutine cmlAddParticlessp_sh(xf, natoms, elements, atomRefs,
coords, occupancies, atomIds, style,
fmt)
ftn-7212 crayftn: WARNING CMLADDPARTICLESSP_SH, File =
m_wcml_molecule.F90, Line = 553
Variable "natoms" is used before it is defined.

subroutine cmlAddParticles_3_sp_sh(xf, natoms, elements, x, y, z,
atomRefs, occupancies, atomIds,
style, fmt)
ftn-7212 crayftn: WARNING CMLADDPARTICLES_3_SP_SH, File =
m_wcml_molecule.F90, Line = 642
Variable "natoms" is used before it is defined.

subroutine cmlAddParticlesdp_sh(xf, natoms, elements, atomRefs,
coords, occupancies, atomIds, style,
fmt)
ftn-7212 crayftn: WARNING CMLADDPARTICLESDP_SH, File =
m_wcml_molecule.F90, Line = 1270
Variable "natoms" is used before it is defined.

subroutine cmlAddParticles_3_dp_sh(xf, natoms, elements, x, y, z,
atomRefs, occupancies, atomIds,
style, fmt)
ftn-7212 crayftn: WARNING CMLADDPARTICLES_3_DP_SH, File =
m_wcml_molecule.F90, Line = 1359

Check and debug if needed.

This is due to the way we handle variable length strings. I have a fix that moves from arrays of characters to a derived type, and this gives a very good speedup (factor of ten). However, there are still cases where this results in segfaults. Needs fixing and merging.

Currently wkml produces a document in the http://earth.google.com/kml/2.2 namespace. However, the current standard defines the namespace as http://www.opengis.net/kml/2.2 (the standard is now maintained by the Open GIS consortium) and wkml created documents thus violate the schema. Clearly we should update the default choice of namespace but the impact on older versions of google earth are not clear. Do we need to maintain a choice of using the old namespace for backwards compatibility?

fox_m_fsys_format.F90 fails to compile with -check all flag

Error:
/tmp/ifortWO02kC.i90: catastrophic error: Internal compiler error: segmentation violation signal raised Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.

Compilation:
ifort -c -check all -DFC_HAVE_FLUSH -DFC_HAVE_ABORT -DFC_ABORT_ARG -DFC_EOR_LF fox_m_fsys_format.F90

Version:
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.1.117 Build 20121010

Attempting to compile with pgi 20.4 I get this error from a call in my code:

call destroy(sdoc)

where sdoc is type(Node)

any ideas?

In an ideal world we would run CI tests with other compilers. PGI have a community edition that looks like it could be installed on travis. See quixdb/squash#217 for an example and #55 for an outline of doing this with Intel (which looks harder). Would help avoid things like #47.

Need to document and test the 'unit' interface for input file echoing on the NWchem branch.

make build installs files, but cmake one doesn't.
It appears that install commands are forgotten.

There is a bug introduced in recent versions of gfortran (6.4.1, 7.3.1 ). These versions raise an internal compiler error when compiling FoX.

I made a bug report to gcc ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 ).

As far as I understand the bug is related to the usage of the len interface to compute the dimensions of the results of character type of many pure functions used for example in fox_m_fsys_format.F90 or in
m_dom_dom.F90.

A workaround that seems to work is to move the routines involved in the len interface at the bottom of their modules, but as explained by a note in the code this clashes with an explicit fortran specification and the modified source is not accepted as valid by other compilers.

A more stable workaround could be to move the len interface to a new module and import the interface.

Using the black formatter I noticed that the following file has python2 syntax and should be updated to python3 since python2 is no longer supported.

wkml/rgb2wkml.py

I think it's mostly the

print "thing"

type of statements need to change to

print( "thing)

So it's easy to do. You can check it with black and tell it what version you want to check it against.

When compiling with some older gfortrans, we get a syntax error:

gfortran -c -fPIC   -DFC_HAVE_FLUSH -DFC_HAVE_ABORT -DFC_EOR_LF  fox_m_fsys_abort_flush.F90 
fox_m_fsys_abort_flush.F90:107.30:

    stop STDERR_FAILURE_STATUS
                              1
Error: Syntax error in STOP statement at (1)

It would be nice if FoX's autoconf stuff was updated to support newer architectures, e.g. aarch64 and ppc64le. I don't really know much about autoconf, but would hope that it's as simple as updating autoconf itself, rerunning whatever generates files like config.sub, and pushing those back in. Is there anyone who already knows how to do this?

We have a bashism in the configure script. The following is from Patrick Welche, with a patch: "Just stumbled across a trivial bashism in FoX (test(1) uses = for string
comparison) - patch attached. "