consiglio per manuale fortran

[Zet]

Sto lavorando a una tesi sulla diffusività di particelle in reticoli, che dovrebbero rappresentare gas in zeoliti. Dato per scontato che ciò non sia granchè di vostro interesse, ho comunque la necessità di utilizzare fortran (lo so che il mondo vive sul C, ma nell'università la tradizione vince sempre).

Già lo faccio, ma ad un livello base che non mi soddisfa, buono solo per scrivere programmi sulle funzioni che mi servono e leggere a grandi linee i programmi altrui scritti per la maggior parte in fortran 77 (il mio prof conosce solo quello). Ma ora mi sono rotto e voglio impararlo + a fondo e mi serve il miglior manuale esistente.

Finora ho usato programmazione strutturata in fortran 77 di Ellis (sono in attesa che a giorni mi arrivi la nuova versione con cenni di 95) e fortran 90 handbook  della mcgraw hill.

Il primo è didatticamente buono (ma un buono che si avvicina più a discreto che a eccellente) ma è obsoleto. Nella versione che ho io non conosce nemmeno i comandi do while (usa goto) o la possibilità di scrivere maggiore uguale come >=. Spero che l'aggiornamente sia migliore.

Il secondo è buono come aggiornamento e contenuti ma fa schifo dal punto di vista didattico (non credo sia quello il suo scopo). Pochi esempi e quelli che ci sono non sono nemmeno molto esplicativi, spiegazioni troppo scarne per funzioni potenzialmente interessanti che quindi non riesco a mettere in pratica (es. cycle).

Consigliatemi voi il migliore manuale per un semi principiante, con molti esempi, scritto bene e aggiornato (e se c'è qualche esercizio risolto sono anche più contento).

grazie a tutti

(b2b)

[bite]

Quanti ricordi!

Il fortran non lo uso più da parecchi anni, l'ultima macchina su cui ho fatto girare un programma fortran era un ControlData (non so neanche se esiste ancora). Quindi purtroppo non ti so segnalare un buon manuale aggiornato.

Devo dire che non sento la mancanza del fortran. Tu perché sei obbligato a usarlo? Parti da un lavoro altrui già scritto in fortran? Il professore ti ci costringe? In questi casi ti do ragione, altrimenti forse potresti considerare il salto al C o addirittura C++, che vanno benissimo per applicazioni numeriche.

In passato mi capitò di occuparmi della diffusione di gas nobili attraverso una matrice di grafite, una cosa semplice semplice, Fick monodimensionale. Immagino che il tuo caso sia ben più complesso perché i reticoli non sono isotropi. Come lo affronti? Boltzmann?

[Zet]

Quanti ricordi!

Il fortran non lo uso più da parecchi anni, l'ultima macchina su cui ho fatto girare un programma fortran era un ControlData (non so neanche se esiste ancora). Quindi purtroppo non ti so segnalare un buon manuale aggiornato.

Devo dire che non sento la mancanza del fortran. Tu perché sei obbligato a usarlo? Parti da un lavoro altrui già scritto in fortran? Il professore ti ci costringe? In questi casi ti do ragione, altrimenti forse potresti considerare il salto al C o addirittura C++, che vanno benissimo per applicazioni numeriche.

In passato mi capitò di occuparmi della diffusione di gas nobili attraverso una matrice di grafite, una cosa semplice semplice, Fick monodimensionale. Immagino che il tuo caso sia ben più complesso perché i reticoli non sono isotropi. Come lo affronti? Boltzmann?

la prima che hai detto. il professore non mi costringe, anzi, mi ha detto che, volendo, potrei riscrivere il tutto in C. Ma, a parte un lavoro notevole, poi mi estranierei dal gruppo di lavoro visto che usano solo fortran.

Tu ora cosa usi? c? c++?

comunque il programma è su un reticolo virtualmente n dimensionale, anche se poi nella pratica lo si fa a 3 dimensioni. Con celle di varie forme e dimensioni che dovrebbero poter rappresentare un gran numero di zeoliti e il gas non è detto che sia nobile, anzi generalmente non lo è. L'approccio è lattice-gas cellular automaton, si semplifica il più possibile per allungare i tempi di studio. Quindi si a ogni cella si assegano un tot di celle, di cui 2*n sono di uscita e le restanti sono interne. Si assegna energie diverse ai 2 tipi di celle (in modo da rappresentare adsorbimento ed energia di attivazione della diffusione da una cella all'altra) e poi si randomizza. Pare che i risultati siano ottimi, ma io sono ancora in fase di preparazione, per i risultati mi manca parecchio. Dovrei lavorare sullo studio di equilibri del gas all'interno del reticolo. Speriamo bene  (good)

Come argomento comunque è molto interessante.

[bite]

Tu ora cosa usi? c? c++?

c++, ormai mi ci sono abituato. Per problemi numerici uso soprattutto le routines di Press+Teukolski+Vetterling+Flannery, Numerical recipes in C. In alcune occasioni mi è tornata utile la GNU Scientific Library.

comunque il programma è su un reticolo virtualmente n dimensionale, anche se poi nella pratica lo si fa a 3 dimensioni. Con celle di varie forme e dimensioni che dovrebbero poter rappresentare un gran numero di zeoliti e il gas non è detto che sia nobile, anzi generalmente non lo è. L'approccio è lattice-gas cellular automaton, si semplifica il più possibile per allungare i tempi di studio. Quindi si a ogni cella si assegano un tot di celle, di cui 2*n sono di uscita e le restanti sono interne. Si assegna energie diverse ai 2 tipi di celle (in modo da rappresentare adsorbimento ed energia di attivazione della diffusione da una cella all'altra) e poi si randomizza. Pare che i risultati siano ottimi, ma io sono ancora in fase di preparazione, per i risultati mi manca parecchio. Dovrei lavorare sullo studio di equilibri del gas all'interno del reticolo. Speriamo bene  (good)

Come argomento comunque è molto interessante.

Senza dubbio; ho dato un'occhiata qui... cose nuove che non conoscevo. L'ultima volta che ho avuto a che fare con l'equazione stazionaria del trasporto ricordo che si usavano le differenze finite nello spazio e delle medie per gruppo energetico (fast/medium/slow), questi nuovi metodi così a naso mi sembrano una via di mezzo tra elementi finiti e montecarlo.

Bene, bene, mannaggia, ti invidio.

Ma quante righe di codice dovresti riscrivere per passare  a c/c++?

[Zet]

Tu ora cosa usi? c? c++?

c++, ormai mi ci sono abituato. Per problemi numerici uso soprattutto le routines di Press+Teukolski+Vetterling+Flannery, Numerical recipes in C. In alcune occasioni mi è tornata utile la GNU Scientific Library.

comunque il programma è su un reticolo virtualmente n dimensionale, anche se poi nella pratica lo si fa a 3 dimensioni. Con celle di varie forme e dimensioni che dovrebbero poter rappresentare un gran numero di zeoliti e il gas non è detto che sia nobile, anzi generalmente non lo è. L'approccio è lattice-gas cellular automaton, si semplifica il più possibile per allungare i tempi di studio. Quindi si a ogni cella si assegano un tot di celle, di cui 2*n sono di uscita e le restanti sono interne. Si assegna energie diverse ai 2 tipi di celle (in modo da rappresentare adsorbimento ed energia di attivazione della diffusione da una cella all'altra) e poi si randomizza. Pare che i risultati siano ottimi, ma io sono ancora in fase di preparazione, per i risultati mi manca parecchio. Dovrei lavorare sullo studio di equilibri del gas all'interno del reticolo. Speriamo bene  (good)

Come argomento comunque è molto interessante.

Senza dubbio; ho dato un'occhiata qui... cose nuove che non conoscevo. L'ultima volta che ho avuto a che fare con l'equazione stazionaria del trasporto ricordo che si usavano le differenze finite nello spazio e delle medie per gruppo energetico (fast/medium/slow), questi nuovi metodi così a naso mi sembrano una via di mezzo tra elementi finiti e montecarlo.

Bene, bene, mannaggia, ti invidio.

Ma quante righe di codice dovresti riscrivere per passare  a c/c++?

a naso ci hai azzeccato, ma non so quanto siano nuovi come metodi, diciamo poco utilizzati in questo tipo di simulazioni. Comunque le linee da tradurre sono parecchie ormai. In + siamo in 4 a lavorarci su (ognuno ha una parte da approfondire) e tutti usano fortran. Ma che vantaggi ha il c++?

[bite]

Se siete in quattro, di cui tre propendono per il fortran, allora la vedo dura.

Il c++ non è la fine del mondo, anzi ha molti difetti. A mio modo di vedere, da un punto di vista teorico è troppo strettamente tipizzato (ma vuole essere così); da un punto di vista pratico, se lo sfrutti a fondo corri il rischio di dover rivedere un pelino il codice ogni volta che cambi o anche solo aggiorni il compilatore (da questo punto di vista il c è molto più portabile se non vai a sfruculiare l'hardware).

I pregi, notevoli, sono che riesce a coniugare l'efficienza del c con il paradigma object oriented, veramente utile perché se te ne sei appropriato risparmi tempo; inoltre essendo così diffuso trovi facilmente supporto (non hai problemi a procurarti un buon libro, li vende a momenti persino il droghiere) e parecchie librerie utili (ad esempio wxWidgets o Qt se ti serve la grafica, più tutte le librerie c, che si linkano senza problemi).