COPILOT

[JohnNichols]

/// <summary>
/// Identifies and updates the primary and secondary peak values and their corresponding indices in the provided
/// metric array, based on the specified frequency and position.
/// </summary>
/// <remarks>This method is intended for internal use in peak detection algorithms, updating
/// multiple references and arrays to track the highest and second highest metric values and their associated
/// frequencies. The caller must ensure that all referenced parameters and arrays are properly initialized
/// before calling the method.</remarks>
/// <param name="FFTMax">A reference to the current maximum peak value found in the metric array. Updated if a higher value is
/// detected.</param>
/// <param name="jFFT">A reference to the index associated with the maximum peak value. Updated when a new maximum is found.</param>
/// <param name="FFTCMax">A reference to the current maximum value for the secondary peak search. Updated if a higher value is
/// detected for the secondary peak.</param>
/// <param name="jCFFT">A reference to the index associated with the secondary peak maximum value. Updated when a new secondary
/// maximum is found.</param>
/// <param name="FFTCSecond">A reference to the second highest value found during the secondary peak search. Updated if a new second
/// highest value is detected.</param>
/// <param name="jSFFT">A reference to the index associated with the second highest secondary peak value. Updated when a new second
/// highest value is found.</param>
/// <param name="c">An array used to store frequency and metric values for the primary and secondary peaks. The method updates
/// its elements with the latest peak information.</param>
/// <param name="d">An array used to store frequency and metric values for the secondary peak. Updated when a new second highest
/// value is found.</param>
/// <param name="Metric">The array of metric values to be analyzed for peak detection. Must not be null.</param>
/// <param name="freq">The frequency value associated with the current metric position. Used to record peak information.</param>
/// <param name="start">The starting index in the metric array for the current analysis. Must be a valid index within the array.</param>
/// <param name="jndex">The current index being evaluated for peak detection. Must be greater than 1 for updates to occur.</param>

I was using C# to fix input data from an accelerometer.  I put up /// as required to list the parameters on a subroutine and in about 20 seconds, COPILOT gave me this to look at.  

It is close enough for me.  When can we expect this in Fortran?

[witwald]

Copilot in Visual Studio 2022 already supports Fortran. Consider the results obtained for subroutine optsol from ularc72.for:

!> SUBROUTINE OPTSOL(A,B,NA,NEQ,LIMS,LIMF,KKK)
!> ---------------------------------------------------------------------
!> Purpose:
!>   Perform operations on a banded linear system stored in packed column
!>   format. The routine has two modes:
!>     KKK = 1 : triangularize (factorize) matrix A in-place.
!>     KKK = 2 : reduce RHS B and perform back-substitution to produce the
!>               solution (B overwritten with solution).
!>
!> Parameters:
!>   A(*)   - REAL, in/out. Packed column storage of the coefficient matrix.
!>            Overwritten by the triangularization when KKK=1; read when KKK=2.
!>   B(*)   - REAL, in/out. Right-hand side on entry; on KKK=2 contains the
!>            solved vector on return.
!>   NA(*)  - INTEGER, in. Index table for packed/band storage (from BANDC).
!>   NEQ    - INTEGER, in. Number of equations (system size).
!>   LIMS   - INTEGER, in. Lower bound used during forward reduction/pivot scan.
!>   LIMF   - INTEGER, in. Lower bound used during back-substitution/elimination.
!>   KKK    - INTEGER, in. Mode selector (1 = factorize A, 2 = reduce B & solve).
!>
!> Notes / Preconditions:
!>   - Arrays A and B are modified in-place.
!>   - NA must correctly describe the packed storage layout (set by BANDC).
!>   - No pivoting is performed; singular or ill-conditioned systems may produce
!>     divide-by-zero or unstable results.
!> ---------------------------------------------------------------------

[JohnNichols]

You have a bridge that is failing according to the human engineers.  They send in the "trained" engineers who say, please survey the bridge.  The problem with cadastral survey is that it is expensive and inaccurate compared to the standard required for bridge monitoring.  So after a while, in Iowa, we will be asked to put the accelerometers and other equipment on the bridge. 

The original problem is that the modern electronics like accelerometers and the YOCTOpuce devices is that they write  controllers in any language except Fortran, the most common language is C#.  The markup language is the standard used for C#.  I asked the YOCTO people for a Fortran controller and I received a less than pleasant response. 

We then run into the engineering problem that one really only does advanced structural analysis in Fortran, although one can get C# and Fortran to talk to each other, it is annoying. So we have data on one side and analysis on the other. Plus there are very few civil or structural engineers who learn Fortran, it is all MATLAB, as they are taught with trivial problems at university, I have a masters student at the moment in structures, who cannot program at all.   

One can look at it as the English problem, you speak English because your elders spoke English, MATLAB is a very poor language for speed or large problems, but it is easy for an engineering lecturer, whose elders spoke MATLAB.  Lemmings over a binary cliff. 

If you want to do Structural Reliability, you are not going to do it with ABACUS or STRAND7, as they are complex and  take too much time.  Maybe in 30 years, but not on the bleeding edge. If you have limited time, then you use the programs developed by the real engineering experts, UCB Powell's group, Harrison and that ilk from the 1970s.  And if you are really lucky, you find this board and Fortran experts. 

The problem in the 1970s is that they had great skills but lacked the data, now we have the data, but they are mostly gone. The 90s replacements could not see a need for Fortran, because ABACUS and Strand7 did the heavy Fortran lifting.  But if you want data out of these programs you need to use Fortran, and we see the endless tribe of students, who ask how to use Fortran or one Fortran subroutine with ABACUS.  

So I have to speak C# as I do not have the time or skills to rewrite the controllers, nor is there a need.  C# is really Microsoft's Fortran replacement, Steve can tell us why Microsoft gave up on Fortran.   It would not be hard to write a scripting language that could produce code in either Fortran or C#.  

So those are some of the problems as to why C# impinges on this board.  

[witwald]

Thank you for the comment regarding the /// lines being in the standard markup language of C#; that was a helpful pointer. It seems to be doing something along the lines of the standard PowerShell structured "Help" that one can include in the comments of scripts to allow the users to see descriptions when they're using the script. I took a look at the YOCTOpuce devices, and although they support a plethora of programming languages, they do avoid Fortran, as was mentioned, which is a bit of a shame. I'm left wondering if they balked at the differences in array storage between Fortran and languages such as C#/C/C++?

I take your points about MATLAB. It can be a slow for larger problems, but having experienced the newer versions, MathWorks has done a lot of work under the hood to speed up MATLAB. The second and subsequent passes through a piece of MATLAB code run much faster than did the first pass. Then the MEX compiler is available to speed up your code once its ready for production use, but of course that's an option that comes at extra cost.

When programming in MATLAB extensively for about 5 years or so, overall I found it a very useful environment to work under, especially if appropriate Toolboxes could be used when needed. The matrix handling out of the box is a real advantage, as is the capability for generating nice plots of results. I guess that sort of combination makes it an attractive and productive choice for many problems. And I suppose Python is the free version of MATLAB in some respects, hence its popularity. Not sure what the speed is like, though, as I haven't done any benchmarking.

I like the Fortran 90/95+ that's now available. It has a lot of built-in array handling that makes sense to someone coming from using MATLAB. If speed is a key requirement, then Fortran programming is the way to go, especially if legacy code can be tapped into.

When it comes to ABAQUS using Fortran subroutines for its consititutive modelling and other purposes, that's not something I've needed to use. However, before working with ABAQUS, I did some work on implementing a penalty element into the PAFEC finite element code. That was all done in Fortran, as we had access to all of PAFEC's source code, whic we needed when porting it to various computer environments that it didn't originally support out of the box.

[andrew_4619]

PAFEC that takes me back in time. I used that a lot back in the late 80s/90s we made some nice software using the PAFEC code as the backbone.  My company was a spinoff from Nottingham University  as in a way was PAFEC   but a bit earlier in time.

[witwald]

@JohnNicholsI noticed the the example you provided is written in some sort of markup language, e.g., <summary></summary>, <param name=""></param>. I'm curious as to why it is being used.

Can you elaborate a little on the purpose of that? Does it interface with some sort of overarching documentation system?