topic http://software.intel.com in Intel® Fortran Compiler

Reference Intel Fortran

JohnNichols — Fri, 02 May 2014 17:23:53 GMT

Steve:

1. I am referring to Intel Fortran 2015 beta in a paper, - How does Intel want the manual documented in the APA Style. I think it is important to indicate the compiler in this case.

2. I tried for 10,000 years of fake earthquake catalogue, got 7000 M8 events, 70,000 M7 events and so on down to M4, at that point the data was 100 GB, I still had 3, 2 and 1 to go. I stopped the program. I will have to look to simplify the data, but I need to represent a date that is 100,000 years down to minutes. Any good ideas?

JMN

http://software.intel.com

TimP — Fri, 02 May 2014 17:37:44 GMT

http://software.intel.com/sites/default/files/managed/cc/c6/Suites_2015_Beta_FAQ.pdf appears to indicate such questions are to be asked on the support account associated with your beta license.

I think we'd prefer that you

Steven_L_Intel1 — Fri, 02 May 2014 17:39:33 GMT

I think we'd prefer that you not reference a beta in a paper. Generically, you could say Intel Visual Fortran Compiler XE 15.0.

Steve:

JohnNichols — Fri, 02 May 2014 17:55:05 GMT

Steve:

I am pretty sure you can answer the questions - they are pretty generic

I enclose the look of the reference list

Usually this manual would be like the name: - so the Compiler 15 is not a problem, just want to make sure I am using the correct numbers

User and Reference Guide for the Intel® Fortran Compiler 14.0

Document number: 328223-002US

Intel® Visual Fortran Composer XE 2013 SP1 - Windows* OS

Intel® Fortran Composer XE

Document number is important ------------------------------- above

How is Intel usually called, Intel -- Intel Inc. etc.

Where do you guys live so I can put a place of publication.

2013 SP1 - Linux* OS, OS X*

We're doing away with the

Steven_L_Intel1 — Fri, 02 May 2014 18:05:35 GMT

We're doing away with the document numbers, so I don't recommend you reference those. Intel is based in Santa Clara, California.

Intel(R) Visual Fortran Composer XE 2013 SP1 is the name of a product that includes a compiler plus other things. Intel(R) Visual Fortran Compiler XE 14.0 is a compiler name/version. Use whichever makes the most sense for your use.

Intel Corporation. (2014).

JohnNichols — Fri, 02 May 2014 19:09:21 GMT

Intel Corporation. (2014). Intel(R) Visual Fortran Composer XE 2013 SP1 Manual. Santa Clara, California: Intel.

Looks good.

Steven_L_Intel1 — Fri, 02 May 2014 19:48:17 GMT

Looks good.

WRT your question on

Paul_Curtis — Sat, 03 May 2014 01:21:52 GMT

WRT your question on representing a date, I use a real value where the integer part is the Julian date, and the fractional part represents the time of day (fractional minutes/86400). This is both compact (32-bits) and has the wonderful property that exact interval arithmetic entails simple addition/subtraction. I have never explored what happens prior to year zero (-2014 from now), and the function likely may not work in that domain. But I also don't think there is an upper limit, so perhaps you could simply add an offset of 100,000 to the year.

[fortran]

FUNCTION julian_date (yyyy, mm, dd) RESULT (julian)
   IMPLICIT NONE
   !          converts calendar date to Julian date
   !          cf Fliegel & Van Flandern, CACM 11(10):657, 1968
   !          example: julian_date(1970,1,1)=2440588
   INTEGER,INTENT(IN)           :: yyyy,mm,dd
   INTEGER                      :: julian
   julian = dd - 32075 + 1461*(yyyy + 4800 + (mm - 14)/12)/4 + &
           367*(mm - 2 - ((mm - 14)/12)*12)/12 -               &
           3*((yyyy + 4900 + (mm - 14)/12)/100)/4
END FUNCTION julian_date

SUBROUTINE get_ymd (jd, yyyy, mm, dd)
   IMPLICIT NONE
   !          expands a Julian date into a calendar date
   !          cf Fliegel & Van Flandern, CACM 11(10):657, 1968
   INTEGER,INTENT(IN)           :: jd
   INTEGER,INTENT(OUT)          :: yyyy,mm,dd
   INTEGER                      :: l,n
   l       = jd + 68569
   n       = 4*l/146097
   l       = l - (146097*n + 3)/4
   yyyy   = 4000*(l + 1)/1461001
   l       = l - 1461*yyyy/4 + 31
   mm       = 80*l/2447
   dd       = l - 2447*mm/80
   l       = mm/11
   mm       = mm + 2 - 12*l
   yyyy   = 100*(n - 49) + yyyy + l
END SUBROUTINE get_ymd

[/fortran]

John,

John_Campbell — Sat, 03 May 2014 06:39:00 GMT

John,

My take from Paul's post is that there are 730,851 days in 2000 years since year 1 or estimated as 52,594,920,000 minutes in 100,000 years.
How you could use this is to use a real*8 variable to represent time in minutes or years.
Certainly the number of minutes would require an interer*8 representation.
I would not go to the detail of leap years.
With the number of earthquake events you are identifying, should you also consider some form of location restriction or are you looking at the whole world. I am also wondering if this study is based on probability of an event taking place anywhere or is there any location reference? There is an argument that events at M4 and below can be "man-made" so the change of this influence over 100,000 years may make these difficult to assess. I suspect this may be what you are studying.

Chris, I was interested to see your Julian day conversion, which is different from one I obtained many years ago. To see two different ways of calculating the year and month effect using integer arithmetic is a revelation. The two use quite different integer dividers.

[fortran]       jdate = 367*yyyy                          &
             - 7*(yyyy+(month+9)/12)/4           &
             - 3*((yyyy+(month-9)/7)/100+1)/4    &
             + (275*month)/9 - 30                &
             + day-1
[/fortran]

Also, what is Julian day 1 ? Is it a significant date?

John

What are the informational

jimdempseyatthecove — Sat, 03 May 2014 12:16:03 GMT

What are the informational requirements for your earthquake data? And are you intending to manipulate the data (or just retrieve it)?

This will aid in suggesting the best algorithm.

Jim Dempsey

If the "fake earthquake

jimdempseyatthecove — Sat, 03 May 2014 12:18:55 GMT

If the "fake earthquake catalog" is an algorithm t generate the data, then don't store the data. Instead, extract the items you need when you need them.

Jim Dempsey