Silverfrost Forums

Welcome to our forums

Fortran fashion designers

15 Jun 2022 9:29 (Edited: 15 Jun 2022 10:27) #29050

Remember i always told here that Fortran with time becomes only younger and will never go into oblivion? How cool way to say in Fortran DO-ENDDO for example ?

Old way:

a=0.
DO i=1,N
  a=a+1.
ENDDO

Hip way:

TYPE(particle_species), DIMENSION(:), POINTER :: species_list
TYPE(particle), POINTER :: current
INTEGER, PARAMETER :: num = KIND(1.e0)
a = 0.0_num
current => species_list(species_id)%attached_list%head
DO WHILE(ASSOCIATED(current))
  a=a+1_num
  current => current%next
END DO

Can anyone explain me how DO loop is working here? I'm really deeply shocked and puzzled 😃

Here are more examples from modern fashion mall of Fortran programming https://github.com/Warwick-Plasma/epoch https://ucla-plasma-simulation-group.github.io/QuickPIC-OpenSource/sourcefile/beam3d_class.f03.html

15 Jun 2022 10:14 (Edited: 16 Jun 2022 1:52) #29051

DanRRight wrote: 'Can anyone explain me how DO loop is working here?'

It is counting the number of links in a linked list.

More links to articles on linked lists in Fortran can be found at https://fortranwiki.org/fortran/show/Linked+list .

15 Jun 2022 10:55 (Edited: 16 Jun 2022 11:50) #29052

Mecej4, How step by step it is doing that? How it know to move to the next particle? How it knows how many particles are in the list to stop DO loop? Here is absent above object with all the rest definitions for head, next etc

  ! Object representing a particle species
  TYPE particle_species
    ! Core properties
    CHARACTER(string_length) :: name
    TYPE(particle_species), POINTER :: next, prev
    INTEGER :: id
    INTEGER :: dumpmask
    INTEGER :: count_update_step

    REAL(num) :: charge
    REAL(num) :: mass
    REAL(num) :: weight
    INTEGER(i8) :: count
    TYPE(particle_list) :: attached_list
    LOGICAL :: immobile
    LOGICAL :: fill_ghosts

    ! Parameters for relativistic and arbitrary particle loader
    INTEGER :: ic_df_type
    REAL(num) :: fractional_tail_cutoff

    TYPE(primitive_stack) :: dist_fn
    TYPE(primitive_stack) :: dist_fn_range(3)

#ifndef NO_TRACER_PARTICLES
    LOGICAL :: zero_current
#endif

#ifdef BREMSSTRAHLUNG
    INTEGER :: atomic_no
    LOGICAL :: atomic_no_set = .FALSE.
#endif

    ! Specify if species is background species or not
    LOGICAL :: background_species = .FALSE.
    ! Background density
    REAL(num), DIMENSION(:,:,:), POINTER :: background_density

    ! ID code which identifies if a species is of a special type
    INTEGER :: species_type

    ! particle cell division
    INTEGER(i8) :: global_count
    LOGICAL :: split
    INTEGER(i8) :: npart_max
    ! Secondary list
    TYPE(particle_list), DIMENSION(:,:,:), POINTER :: secondary_list

    ! Loading of particles
    REAL(num) :: npart_per_cell
    TYPE(primitive_stack) :: density_function, temperature_function(3)
    TYPE(primitive_stack) :: drift_function(3)

    ! Thermal boundaries
    REAL(num), DIMENSION(:,:,:), POINTER :: ext_temp_x_min, ext_temp_x_max
    REAL(num), DIMENSION(:,:,:), POINTER :: ext_temp_y_min, ext_temp_y_max
    REAL(num), DIMENSION(:,:,:), POINTER :: ext_temp_z_min, ext_temp_z_max

    ! Species_ionisation
    LOGICAL :: electron
    LOGICAL :: ionise
    INTEGER :: ionise_to_species
    INTEGER :: release_species
    INTEGER :: n
    INTEGER :: l
    REAL(num) :: ionisation_energy

    ! Attached probes for this species
#ifndef NO_PARTICLE_PROBES
    TYPE(particle_probe), POINTER :: attached_probes
#endif

    ! Particle migration
    TYPE(particle_species_migration) :: migrate

    ! Initial conditions
    TYPE(initial_condition_block) :: initial_conditions

    ! Per-species boundary conditions
    INTEGER, DIMENSION(2*c_ndims) :: bc_particle
  END TYPE particle_species

And is it legal to use TYPE definition for next, prev inside the TYPE definition which is not yet defined (first few lines of this TYPE particle_species before END TYPE particle_species) ???

  TYPE particle_species
    ! Core properties
    CHARACTER(string_length) :: name
    TYPE(particle_species), POINTER :: next, prev
.............
END TYPE particle_species

UPDATE: thanks for the link i did not see initially. I will try to find some simple examples which i will be able to go step by step with the SDBG debugger.

Pity FTN95 can not compile Warwick EPOCH code, in this case how it works would be clear in minutes as soon you open it in the debugger

16 Jun 2022 8:52 #29055

Compiling this code with latest Intel Fortran takes 6-7 minutes on supercomputer. FTN95 on PC would do that in 6-7 seconds.

18 Jun 2022 4:00 #29062

Dan,

I'm pleased that you are still a fan of compiling with FTN95.

When I got a PC with a 486 and 16Gb RAM, I was able to run bigger problems than were possible on mainframes at 2 of the UK's leading Universities (I'll keep their names secret to save embarrassment). However, I didn't then expect the compilation to be faster, and as for execution, if the mainframe couldn't handle the problem, there was no way to compare.

Eddie

18 Jun 2022 6:10 #29063

'When I got a PC with a 486 and 16Gb RAM,...'

Tall tales, Eddie. A 486 could not address 16 Gb. You had 16 Mb, may be?

I once had a 486 PC with 4 memory modules, each with 8 Mb of SDRAM.

19 Jun 2022 9:45 #29064

Memory - human as well as computer - sometimes fails, after a long time. Of course it wasn't Gb, it was Mb - slip of the keyboard.

My 486 was the 66 clock multiplied version, and replaced a 386SX. I went to Dan computers around the back of the old Wembley stadium and bought the thing one Christmas Eve for cash. To get the 100 MHz AMD version, it needed a new motherboard in probably the hugest tower machine I ever had. The original probably had 4Mb RAM, and even then, one needed DBOS and/or some form of DOS extender that I can't remember now.

At that point, I was indulging in the sort of thing that Dan seems to do, which is a fervid change of computer with every new release of chip, probably involving a new motherboard, sometimes different (and bigger) hard drives and probably new and bigger memory sticks.

It was the last Intel machine I ever had, and I''ve used AMD ever since, and not only that, apart from laptops, I have built my own.

I always thought of those machines as 486s, but of course the AMD nomenclature was somewhat derivative of the x86 naming and rather different to Pentium, which is probably why I couldn't recall which one it was, lumping all of them into the 486 bucket. So the 16Mb probably wasn't on the real Intel 486DX2 but on an AMD equivalent.

I've had to have Intel chip laptops from time to time even though my preference is AMD. My old Uni only ever provided Intel machines for staff., usually the lowest spec they could get away with, reserving high powered machines for secretaries (who also got huge monitors) so that they could run WordPerfect nicely, whereas to run things like Finite Element software I had to work from home, a habit that served me well when I retired, and during the Covid lockdown!

I note that when I visit my former colleagues they are using supplied machines of decidedly inferior spec, but now that a couple of Gb (and yes, I do mean Gb this time) seems standard, and cpus are so much faster, it hardly seems to matter at all.

Thanks for the correction.

Eddie

20 Jun 2022 6:57 #29065

Eddie, When heavy work with the code development takes place i recompile hell amount of times per day. And when waiting for finish always one thing comes to mind: just lose 3 seconds per day and you will lose 3 working days ( 8 hours a day) over entire life. Waiting for compilation is pure 100% loss of time. And now imagine losing not 3 seconds but 3 minutes, 30 minutes total - hard to believe, but that's 180 days, 1800 days of waiting 😭

4 Jul 2022 7:45 #29144

Try to feel my pain. On effing supercomputers you change one symbol and compilation even with MAKE utility (which only recompiles the file you just edited) still takes 1 min at least.

Please login to reply.