Diskless API writes `fort.26` file containing dipole information

Describe the bug
Calling mopac_scf from C code creates the file fort.26 in the working directory. This is more of an annoyance than a real issue, and part of this report is checking if I'm missing an option to turn off this output? I reread the docs in the header file and searched a bit in the repo, so hopefully I didn't miss anything.

To Reproduce
I'm using the same C code and Makefile as in #220, minus the run_mopac_from_input call:

#include <stdio.h>

#include <mopac.h>

typedef struct mopac_system mopac_system;
typedef struct mopac_state mopac_state;
typedef struct mopac_properties mopac_properties;

int main() {
        int atom[5] = {6, 6, 6, 1, 1};
        double coord[15] = {
                0.000000000000, 0.003768239200, -1.686245109400,
                0.000000000000, 1.243805099800, 0.688097726900,
                0.000000000000, -1.242134139500, 0.700109341300,
                0.000000000000, 2.998368900600, 1.719180578800,
                0.000000000000, -3.003808100200, 1.718996398400,
        };
        mopac_system system = {
                .natom = 5,
                .natom_move = 5,
                .charge = 0,
                .spin = 0,
                .model = 3,
                .epsilon = 1.0,
                .atom = atom,
                .coord = coord,
                .nlattice = 0,
                .nlattice_move = 0,
                .pressure = 0.0,
                .lattice = NULL,
                .tolerance = 1e-8,
                .max_time = 1,
        };

        mopac_state state = {};

        mopac_properties props = {};

        mopac_scf(&system, &state, &props);

        printf("nerrors: %d\n", props.nerror);

        for (int i = 0; i < props.nerror; i++) {
                printf("%s\n", *props.error_msg++);
        }

        printf("%f\n", props.heat);

        return 0;
}

MOPAC_PATH := /home/brent/Packages/arch-packages/mopac/src/mopac-23.0.1

main: main.c
        gcc -Wl,-rpath,$(MOPAC_PATH)/build -I $(MOPAC_PATH)/include -L $(MOPAC_PATH)/build -lmopac -o $@ $^

The contents of the fort.26 file look like this:

 DIPOLE           X         Y         Z       TOTAL
 POINT-CHG.     0.000    -0.039    -1.226     1.227
 HYBRID         0.000     0.007     0.770     0.770
 SUM            0.000    -0.031    -0.456     0.458





            (VALENCIES)   BOND ORDERS

     1  C     (1.997)     2  C 0.997     3  C 0.987

     2  C     (2.581)     1  C 0.997     4  H 0.940     3  C 0.616     5  H 0.028

     3  C     (2.574)     1  C 0.987     5  H 0.941     2  C 0.616     4  H 0.030

     4  H     (0.990)     2  C 0.940     3  C 0.030     5  H 0.015

     5  H     (0.991)     3  C 0.941     2  C 0.028     4  H 0.015

Expected behavior
I expected no files to be created in the working directory.

Operating system
Arch Linux

Additional context
From searching the contents of the file, I think the printing is triggered by the mode argument to the dipole function:

mopac/src/properties/dipole.F90

Line 166 in c92b082

if (mode == 1) write (iw, 140) ((dip(i,j),i=1,4),j=1,3)

But I didn't follow the callstack any farther up.

Thanks again for your attentiveness in catching bugs, I did not notice this stray file. During the "diskless" API calls, I'm piping most output to a null location rather than remove it to avoid adding a lot of clutter to the code. The null location looks like a file, but it is effectively instructing the Fortran compiler to ignore the outputs. What appears to be happening is that I'm closing the "file handle" to the null location a bit too early because I didn't notice outputs being generated during my post-processing phase. When outputs are written after this file handle is closed, they seem to be appearing in this fort.26 file. This is probably some kind of compiler debug mechanism, as write commands to an invalid file handle should be flagging an error (MOPAC does not attempt to catch and handle errors in typical calls to write). I just need to close the null file handle a little bit later, and this should go away. I'll probably issue an immediate patch for this, too, because the API is being advertised as "diskless", and this bug is interfering with that claim.

Awesome, thanks again for the quick fix!