From: <rsault_at_email.protected>
Date: Thu, 14 Sep 2006 15:11:43 +1000 (AUS Eastern Standard Time)

Simon,

Because miriad stores data on disk in a system independent format (like
FITS), conversion between the native machine formats and the disk format
is performed within Miriad. The disk number formats used by Miriad are the
same as FITS number formats.

mirupdate contains the path of source code to compile, and so would need
to be changed to pick the low-level code that expects the x86 byte order.
The mircadd script will also need some change. Currently the
file sysdep.h has a define statement related to byte order. Either
you can leave sysdep.h unchanged, and use the "-Dlinux" flag to the
C compiler, or you can change sysdep.h and mircadd.

Below is some notes I wrote a while back on the steps needed to port
Miriad to an x86 Darwin machine. The Miriad build environment is designed
to readily handle these sorts of variations. So I assume once the dust has
settled a x86 Darwin scripts subdirectory will be makde to handle all of
it seemlessly to users.

If the RPFITS library is working for ASAP, then nothing should need to
happen with this.

Best regards
Bob

>Regarding an Intel Mac ... I do not foresee any particular issue
>supporting this. Just the normal issue of do you want to support another
>environment, and the issues of the Mac environment still evolving
>rapidly. Because the byte order is different (I assume!) from the
>existing Macs, it would need to be handled as a separate installation
>script directory. You would need to create a separate "unix/scripts"
>subdirectory (probably copy the linux subdirectory) and modify compiler
>flags as needed in the mircadd and mirclnk scripts, modify the
>corresponding mirupdate.csh "dosubs" line to the same as the LINUX
>corresponding file, change MIRRC and MIRRC.sh to detect and name the
>machine type as an Intel Mac when a user logs in.

--
------------------------------------------------------------------------
Bob Sault
Email: rsault_at_optusnet.<!--nospam-->com.au
Web:   http://members.optusnet.com.au/rsault
On Thu, 14 Sep 2006, Simon Ellingsen wrote:
> Hi Bob,
>
>> Because the byte order is different on x86 and ppc (I think!), there would 
>> be a need to make some changes to mirupdate. Did you do this? Without the
>> change, miriad would probably mostly work - but the files produced would 
>> not be usable by any other system, nor could you read/write FITS files
>> (not sure about RPFITS).
>
> No I didn't.  I haven't tried loading any data in yet.  I did the initial 
> compilation a few months ago, but haven't had a chance to actually process 
> data with it.  From what you say it sounds like more needs to be done before 
> I can anyway.  The RPFITS libraries work OK because I have used them to do a 
> bit of processing of some single dish correlator data in ASAP 2.1.  Does 
> mirupdate change atlod, or just other FITS related tasks?
>
> Regards
>
> Simon
> --
> Simon Ellingsen : Senior Lecturer Physics & Astronomy, University of Tasmania
> email : Simon.Ellingsen_at_utas.<!--nospam-->edu.au
> WWW   : http://www-ra.phys.utas.edu.au/~sellings
> Phone : 6226 7588 ;                       Area Code : +61 3 (International)
>       6278 8636 (Home), 6226 2410 (Fax)                03 (Australia)
>
>
>

Received on 2006-09-14 15:12:03