View Full Version : [.NET] Cose di pazzi!!!
Da non credere... sono incazzatissimo... non credo ai miei occhi... vi prego, spiegatemi se sono pazzo...
Ecco come lavora la funzione math.round in .NET
math.round(9.5) = 10.0
math.round(10.5) = 10.0
math.round(11.5) = 12.0
math.round(12.5) = 12.0
:eek: :eek: :eek: :eek: :eek: :eek:
COSE DA NON CREDERE!!!
Dennissoraga
20-07-2004, 19:13
hai provato a vedere con la virgola come va?
A prima vista (di un cieco, dato che in matematica io sono una seg@) potrebbe essere un arrotondamento allla metà pari. Se la cifra è equidistante dagli estremi arrotonda verso l'estremo pari. Dalla documentazione di tutt'altro linguaggio pare che questo sia il sistema che minimizza l'errore cumulativo in caso di applicazione ripetuta.
Magari .NET usa questo.
Ciao.
ciao PGI,
non ho ancora controllato ma effetivamente un amico ing. che ho rivisto stasera dopo tempo (il mitico ciro (http://www.alepav.too.it)) mi diceva di ricordarsi qualcosa del genere dal corso di fisica 1 (1000 anni fa :( ) che una approssimazione al numero pari più vicino viene effettuata per evitare, nel caso di divisione per due, di ri-ottenere un altro dispari... :confused: non so se è vero (io non me lo ricordo) ma mi sembra cmq una str***ata!!!!
;)
Originariamente inviato da Dennissoraga
hai provato a vedere con la virgola come va?
non è possibile... riconosce solo numeri col punto....
/\/\@®¢Ø
20-07-2004, 22:23
Originariamente inviato da cipi
Da non credere... sono incazzatissimo... non credo ai miei occhi... vi prego, spiegatemi se sono pazzo...
Ecco come lavora la funzione math.round in .NET
math.round(9.5) = 10.0
math.round(10.5) = 10.0
math.round(11.5) = 12.0
math.round(12.5) = 12.0
:eek: :eek: :eek: :eek: :eek: :eek:
COSE DA NON CREDERE!!!
Non tutti i numeri decimali sono rappresentabili in virgola mobile.
Di conseguenza anche se tu scrivi 9.5 , 10.5 , 11.5 etc.
in realta' poi il compilatore usa il numero piu' vicino scrivibile con un real (o un double). Il problema e' che per alcuni numeri il valore piu' vicino e' piu' grande, per altri e' piu' piccolo.
Nel nostro caso evidentemente, per 9.5 e 11.5 la rappresentazione piu' vicina e' piu' grande, mentre negli altri due e' piu' piccola.
/\/\@®¢Ø
20-07-2004, 22:32
Tra l'altro non mi sembra che ci sia uno standard che definisca come fare questi arrotondamenti (intendo dire decimale -> virgola mobile) tanto che sotto python mi arrotonda sempre per eccesso, sbagliando pero' per i numeri un po' sotto alla meta' (che arrotonda per eccesso)
Originariamente inviato da cipi
Da non credere... sono incazzatissimo... non credo ai miei occhi... vi prego, spiegatemi se sono pazzo...
Ecco come lavora la funzione math.round in .NET
math.round(9.5) = 10.0
math.round(10.5) = 10.0
math.round(11.5) = 12.0
math.round(12.5) = 12.0
:eek: :eek: :eek: :eek: :eek: :eek:
COSE DA NON CREDERE!!!
questo succede quando si usano linguaggi WC.NET fatti col/per il culo :rotfl:
ma poi che arrotondi a fare, devi andare a botte di 14 cifre significative altro che gli arrotondi ...
l'arrotondo lo devi fare sulle curve della tua morosa (if any ... :D )
col tuo WC.NET, se proprio non è un cesso come da nome, prova math.int(x + 0.5) e vedi che va tutto a posto :p
Originariamente inviato da /\/\@®¢Ø
Tra l'altro non mi sembra che ci sia uno standard che definisca come fare questi arrotondamenti (intendo dire decimale -> virgola mobile) tanto che sotto python mi arrotonda sempre per eccesso, sbagliando pero' per i numeri un po' sotto alla meta' (che arrotonda per eccesso)
ecco python invece, sempre come suggerisce il nome, non è fatto col/per il culo ma con la/per la passera e infatti fa quel ca@@o che vuole lui :D
ragazzi ma quand'è che vi deciderete a programmare con un linguaggio serio ? :cool:
AnonimoVeneziano
20-07-2004, 22:46
Originariamente inviato da a2000
ecco python invece, sempre come suggerisce il nome, non è fatto col/per il culo ma con la/per la passera e infatti fa quel ca@@o che vuole lui :D
:rotfl:
Originariamente inviato da a2000
questo succede quando si usano linguaggi WC.NET fatti col/per il culo :rotfl:
...uso VB.NET ma che sia fatto col culo per molti versi è vero... :(
ma poi che arrotondi a fare, devi andare a botte di 14 cifre significative altro che gli arrotondi ...
l'arrotondo lo devi fare sulle curve della tua morosa (if any ... :D )
lasciamo stare... :incazzed:
col tuo WC.NET, se proprio non è un cesso come da nome, prova math.int(x + 0.5) e vedi che va tutto a posto :p
Esiste? Non nella piattaforma .NET!!! Magari ne hanno creata una per te... :rotfl: :eheh:
eh adesso non c'è la conversione all'intero anche nel tuo WC.NET ?! :eek:
impossibile.
end.is.forever
21-07-2004, 08:46
Adesso non esageriamo, fatto col culo...
che abbia ancora alcuni difetti ok, ma lasciamogli il tempo di fixarli
Non è fuori da molto tempo, il numero 1.1 la dice lunga sulla loro consapevolezza di dovere ancora starci sotto, e per la mole di lavoro che hanno dovuto fare, secondo me è già un ottimo risultato.
Io mi ci trovo abbastanza bene quando faccio qualcosa di non troppo memory intensive, e per me è il miglior prodotto Microsoft mai creato.
Ciao.
Originariamente inviato da a2000
eh adesso non c'è la conversione all'intero anche nel tuo WC.NET ?! :eek:
impossibile.
Intendo dire che nella classe System.Math nn c'è .int !!! Al massimo System.Convert.Int32 ecc. ma funzionano allo stesso modo del round :(
Per il momento ho sistemato con System.Math.Floor e ho modificato l'algoritmo...
Cmq il comportamento di quello strano arrotondamento è dovuto addirittura ad uno standard: Standard IEEE 754, sezione 4 !
:eek: :eek: :eek:
Originariamente inviato da end.is.forever
... e per me è il miglior prodotto Microsoft mai creato.
E il dos dove lo metti??? :D :D :D ;)
AnonimoVeneziano
21-07-2004, 12:41
Originariamente inviato da cipi
E il dos dove lo metti??? :D :D :D ;)
nella spazzatura
Originariamente inviato da AnonimoVeneziano
nella spazzatura
:eheh:
repne scasb
21-07-2004, 20:39
Originariamente inviato da a2000
ragazzi ma quand'è che vi deciderete a programmare con un linguaggio serio ? :cool:
e sarebbe? Fortran? :asd: :D
Originariamente inviato da repne scasb
.....
Rimane comunque chiaro che se si deve utilizzare la "matematica" "seriamente" e non si vuole incorrere nei problemi citati da cipi, l'unico linguaggio di programmazione da utilizzare e' il fortran (consiglio cipi di apprenderlo).
...
oooooooooooooooooooooooooooooooooooooooooooooooooooooohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
questo si chiama parlare !!!!!!
Originariamente inviato da abxide
e sarebbe? Fortran?
fortran uber alles = metà delle righe di codice, 20 volte la velocità di calcolo.
tutto il resto è silenzio, anzi fastidioso e inutile rumore :D
“Rapne Scasb, sento la Forza della Sborone fluire nelle tue parole.
Il Lato Oscuro, dopo secoli di oscurità, è tornato alla luce, si è mostrato di nuovo, più forte di prima.
E’ questa la vera Forza, Jedi.”
la Forza sarebbe il Forztran ... per chiarezza. :D :cool:
Originariamente inviato da a2000
fortran uber alles = metà delle righe di codice, 20 volte la velocità di calcolo.
Non mi editare le faccine :sofico: :ciapet:
senti abxide ma tu abbitti ngopp o' vomero o inde i vash ? :D
Originariamente inviato da a2000
senti abxide ma tu abbitti ngopp o' vomero o inde i vash ? :D
Sotto o vomero e a for o dash :ciapet: :D
o stai sol' a scass'o cash ? :D
Originariamente inviato da a2000
o stai sol' a scass'o cash ? :D
uaa quando inizi non la finisci più eh :D
Siamo leggermente off topic, quindi passo e chiudo. :O :sofico:
vabbuo' "for o dash"
si stai mut' comm o' pesh
mang' caud e mang fresh
i me vag a curca abbash.
buonanotto a tutti sti signuri incruwattati. :O
repne scasb
21-07-2004, 23:27
maxithron
21-07-2004, 23:39
Ma credo che questo sia abbastanza chiaro, nel senso che ogni linguaggio ha uno scopo ben preciso. Non ho mai creduto che esista IL linguaggio. E' anche sostanzialmente raro il caso in cui una qualsiasi persona riesca ad essere padrona di più tipi di linguaggi, in genere, si tende a perfezionarsi su ciò che più è adatto ai propri scopi.
Solitamente è un 3d quasi ciclico in questa sezione. Altre volte ho visto sondaggi, richieste di quale sia IL miglior linguaggio, ma personalmente non credo che abbia molto senso questa cosa.
Anche perchè se è vero che il fortran è indubbiamente il più adatto per lavorare con funzioni matematiche complesse, non ho però mai sentito parlare (almeno non ancora) di un sistema operativo scritto in fortran. Non che sia importante o una sorta di "guardate che con questo non si può etc.... e scemenze varie". Solo che il linguaggio io lo vedo come un mezzo per arrivare ad un fine ben specifico. Chiaro che se ho la possibilità di poter lavorare con linguaggi che in determinati campi sono altamente efficienti, non vedo perchè vincolarmi a qualche tipo di assurda "fede" o "fanatismo" che dir si voglia.
Originariamente inviato da maxithron
...
Anche perchè se è vero che il fortran è indubbiamente il più adatto per lavorare con funzioni matematiche complesse, non ho però mai sentito parlare (almeno non ancora) di un sistema operativo scritto in fortran. Non che sia importante o una sorta di "guardate che con questo non si può etc.... e scemenze varie". Solo che il linguaggio io lo vedo come un mezzo per arrivare ad un fine ben specifico.
....
ma poichè il fine originario e di gran lunga più importante della programmazione è il calcolo numerico ecco che il fortran è Il linguaggio di programmazione.
Originariamente inviato da repne scasb
Vorrei chiarire che il lato e' oscuro per chi non vede chiaro, per chi non vede oscuro e' sempre stato chiaro; spero di aver chiarito senza essere stata oscura.
A conferma di cio' riporto una mia esperienza personale circa "i linguaggi di programmazione".
Da alcuni anni lavoro ad un simulatore reolitico che nelle intenzioni dovrebbe "predire" il comportamento di un certo materiale in stato viscoelastico nei processi di estrusione. Una delle routine piu' "rognose" e contemporaneamente piu' complesse era soggetta a propagazione d'errore per arrotondamento, a causa della estrema nidificazione della stessa. Riporto i risultati di una variabile di processo rispetto al linguaggio (il cui nome non interessa), fissate tutte le altre variabili:
visto che sei oscura e non oscuro dovresti per tua natura sapere che: il lato oscuro è sempre stato per chi vede chiaro, il lato chiaro lo offre invece chi vede oscuro.
e così chi vede chiaro sta all'oscuro e chi vede oscuro espone al mondo il chiaro.
ma ti stai ammazzando di tensori e derivate convette ?
butta via i metodi puramente numerici, quelli che partono per la tangente e non si sa dove vanno a parare.
e passa sempre attraverso una soluzione/integrazione analitica approssimata del tuo set di equazioni.
in altre parole non esiste algoritmo numerico veloce e robusto senza una inner routine che integri/risolva per quadratura analitica.
repne scasb
22-07-2004, 08:43
repne scasb
22-07-2004, 08:46
Originariamente inviato da repne scasb
Di questo sono convinta, il problema e' trovarlo.
semplice anzi SIMPLER .... volumi finiti, nested grid, algoritmo intrinsecamente parallelo.
funziona anche per T = -pI + 2µ(D,t)D +eE
Originariamente inviato da repne scasb
quote:
--------------------------------------------------------------------------------
Originariamente inviato da a2000
visto che sei oscura e non oscuro dovresti per tua natura sapere che: il lato oscuro è sempre stato per chi vede chiaro, il lato chiaro lo offre invece chi vede oscuro.
e così chi vede chiaro sta all'oscuro e chi vede oscuro espone al mondo il chiaro.
--------------------------------------------------------------------------------
Ma se cio' che e' chiaro e' l'oscuro, e cio' che e' oscuro e' il chiaro, perche non chiamiamo l'oscuro chiaro, e il chiaro oscuro?
no la cosa è molto più chiara:
il lato oscuro del desiderio () è sempre stato dato (data) a chi vede chiaro.
mentre il lato chiaro del desiderio, dove non batte il sole, è sempre stato esposto, suo malgrado, da chi vede oscuro.
repne scasb
22-07-2004, 09:14
mah non mi piace .... comunque la fase 4 mi sembra fatta apposta per un approccio fuzzy-reti neurali.
comunque se precisi meglio il problema: è la determinazione del campo di moto-deformazione, P, T, x (composizione) in un volume definito, a frontiera libera .... ?
repne scasb
22-07-2004, 10:26
repne scasb
22-07-2004, 10:31
Originariamente inviato da repne scasb
Non piace neanche a me. Ti espongo per sommi termini il problema: fai conto di avere un cilindro alla cui base c'e' un ugello.
...
molto bello. complimenti.
che algoritmo utilizzate ?
un volumi finiti potrebbe essere la morte sua.
sarebbe anche interessante un modello parzialmente integrato plug-flow.
:)
repne scasb
22-07-2004, 12:37
repne scasb
22-07-2004, 12:42
tu le chiami "voglie" eh ..... mi piacerebbe conoscerti .
sono quelle che in termini meno Jedi ... si definiscono flussi di massa, calore, quantità di moto e che sono legati da equazioni costitutive caratteristiche del materiale ai gradienti di concentrazione, temperatura, deformazione.
il set di equazioni risolutive standard per problemi simili è questo:
equazione di continuità
bilancio locale qtà di moto
bilancio locale energia
bilanci locali di massa singoli componenti
equazione costitutiva tensore degli sforzi
equazione costitutiva flusso termico
equazioni costitutive flussi di massa
equazioni costitutive termini generativi di massa (cinetiche)
equazioni equilibrio alle interfacce
condizioni iniziali e al contorno
e sarebbe divertente poterle risolvere con qualche collega fantasiosa e piena di "voglie".
:)
repne scasb
22-07-2004, 13:30
P.S.
ti consiglierei caldamente un approccio rigorosamente euleriano del problema anche nel caso in cui ci siano particelle, fasi disperse e segregate che potrebbero portare "naturalmente" ad una descrizione di tipo lagrangiano.
si tratta "solo" di scrivere e risolvere il set di equazione per ogni fase con le opportune equazioni per i flussi interfacciali.
Originariamente inviato da repne scasb
Nel corso degli anni la routine si e' "naturalmente" semplificata. Non tutte le equazioni "pesano" nello stesso modo, ho imparato a capire quali pesano (in funzione delle condizioni iniziali) e quali no (perspicace io). Oggi la routine e' molto snella e veloce, e gira comodamente su un normale PC. Mi rammarico di non poter scendere nei dettagli, ma "non mi e' permesso".
brava !
ma penso di poterti aiutare: ti prometto -40% delle righe di codice, - 30% memoria, + 70% velocità di calcolo.
assumete ?
per lavorare con te, vengo via alla pari: 90000 €/y.
repne scasb
22-07-2004, 14:10
maxithron
22-07-2004, 14:42
Originariamente inviato da repne scasb
Se ti dicessi, cosi' informalmente..........che il problema viene risolto da un "automa cellulare", rimarresti spiazzato, o interessato?
Se è un automa cellulare di 4a classe, a2000 diventerà l'uomo più felice del pianeta :D
repne scasb
22-07-2004, 15:00
Originariamente inviato da repne scasb
Se ti dicessi, cosi' informalmente..........che il problema viene risolto da un "automa cellulare", rimarresti spiazzato, o interessato?
al corrente delle mode e viste le "voglie" lo sospettavo ....
no matter comunque: interessato per 95000 €/y.
(sempre prezzo di favore per lavorare sotto di te )
repne scasb
22-07-2004, 15:10
penso proprio di sì: da ottobre ! :D
comunque do il mio contributo agli automi e alle "voglie" ....
maxithron
22-07-2004, 15:55
Originariamente inviato da a2000
penso proprio di sì: da ottobre ! :D
comunque do il mio contributo agli automi e alle "voglie" ....
a2000, riusciresti ad 'estraniarlo' da excel e da vba dato che uso linux?
Mi farebbe molto piacere vederlo. thx.
Qualche uccellino ti ha detto che sono stato dalle tue parti di recente?
Originariamente inviato da maxithron
a2000, riusciresti ad 'estraniarlo' da excel e da vba dato che uso linux?
Mi farebbe molto piacere vederlo. thx.
Qualche uccellino ti ha detto che sono stato dalle tue parti di recente?
mah ... è abbastanza embedded.
e quali sarebbero "le mie parti" ... ? :D
dimmelo perchè ultimamente non lo so neanch'io.
maxithron
22-07-2004, 16:13
Originariamente inviato da a2000
mah ... è abbastanza embedded.
e quali sarebbero "le mie parti" ... ? :D
dimmelo perchè ultimamente non lo so neanch'io.
ti rispondo in pvt ;)
Originariamente inviato da repne scasb
Rimane comunque chiaro che se si deve utilizzare la "matematica" "seriamente" e non si vuole incorrere nei problemi citati da cipi, l'unico linguaggio di programmazione da utilizzare e' il fortran (consiglio cipi di apprenderlo).
Già lo uso... fortran, C, java ecc. ma sto imparando .NET e inoltre mi sono davvero utili delle sue potenzialità che ti permettono di interfacciarti rapidamente con altri files dell'ambiente windows... sai benissimo che fortran, tranne giri iperbolici, non è molto potente in questo... :(
scusate il ritardo ma ero in ferie :D :D :D
Originariamente inviato da repne scasb
Ti manca un pezzo del puzzle. In sostanza la routine iterativa fa questo:
1) Inizializzazione
2) Inizio loop
3) Calcolo numerico
4) Test e correzione manuale
5) Test uscita loop
6) Continua loop
La fase fondamentale e' la 4). In sostanza il problema e' un problema fisico-matematico; io non conosco dove si trova la soluzione, ma conosco dove non si trova "sicuramente", perche' conosco il meccanismo fisico che genera il problema (o almeno credo di conoscerlo); nella fase 4) "spingo" le variabili che mi interessano nella "giusta" (secondo me) direzione. In sostanza al passo "n" la variabile "v" vale "c", testo e "decido" che "v" non vale "c" ma "c+a". Questo tipo di correzione mi ha sempre fatto sorgere il dubbio che: manca "qualcosa" nelle equazioni di modo nello stato viscoelastico. Spero di non averti annoiato.
Perchè non utilizzi un algoritmo genetico? Potresti introdurre dei constraints che guidino la soluzione nel campo delle soluzioni feasible!
E poi... non ci sono dei software che simulano già quello che cerchi di simulare tu? Mi par di ricordare di si...
ciao
Originariamente inviato da repne scasb
Lo standard IEEE 754 definisce le modalita' con cui una quantita' numerica di tipo "float" puo' essere trasformata in binario rispettivamente con 32 bit e con 64 bit (una piccola guida e' disponibile presso: http://research.microsoft.com/~holl.../ieeefloat.html)
Ora, poiche' il numero di combinazioni date da 32 bit o 64 bit sono finite mentre un numero "float" puo' essere rappresentato da un numero infinito di cifre, ne risulta che non tutti i numeri decimali sono convertibili univocamente secondo lo standard IEEE 754.
Dalla considerazione del precedente paragrafo scaturisce la sezione ANNEX D - IEEE-754 round-to-nearest-value mode, che non c'entra nulla con il problema di arrotondamento dato da .NET (con cui credo che cipi si sia confuso). ecc. ecc.
... avevo solo riportato quanto scritto nella guida online di .NET! Se è come dici tu sono loro che si sono confusi :sofico:
Originariamente inviato da cipi
Già lo uso... fortran, C, java ecc. ma sto imparando .NET e inoltre mi sono davvero utili delle sue potenzialità che ti permettono di interfacciarti rapidamente con altri files dell'ambiente windows... sai benissimo che fortran, tranne giri iperbolici, non è molto potente in questo... :(
...
che fritto misto ! dove lo hai pescato ? :D :D
vero minga.
pensa che Fortran Power Station scrive file binari e strutture dati miste con lo stesso standard del VisualBasic.
questo vuol dire che puoi scambiare informazioni in formato binario senza passare da formattazioni in chiaro. :cool:
inoltre, per sfatare un'altra leggenda, la manipolazione stringhe in fortran è potente e anche più sintetica addirittura di quella in VB.
Originariamente inviato da cipi
Perchè non utilizzi un algoritmo genetico? Potresti introdurre dei constraints che guidino la soluzione nel campo delle soluzioni feasible!
E poi... non ci sono dei software che simulano già quello che cerchi di simulare tu? Mi par di ricordare di si...
ciao
per carità: fuori gli OGM dalla Navier-Stokes ! :D
certo che ci sono software per la fluidodinamica di fluidi non-newtoniani.
solo che .... qualcuno ..... da qualche parte nel mondo .... li dovrà pure scrivere o no ?!!! :confused: :D
e quel qualcuno siamo noiiiiii ! :D :D
Originariamente inviato da a2000
per carità: fuori gli OGM dalla Navier-Stokes ! :D
no, non mi dire così.... ciò significherebbe che il mio lavoro è inutile... :cry: :D :D
Originariamente inviato da a2000
certo che ci sono software per la fluidodinamica di fluidi non-newtoniani.
solo che .... qualcuno ..... da qualche parte nel mondo .... li dovrà pure scrivere o no ?!!! :confused: :D
e quel qualcuno siamo noiiiiii ! :D :D
giusto... ma penso anche che chi DEVE PRODURRE (il che significa che l'azienda pretende un ottimo prodotto in poco tempo) sia spesso costretto ad affidarsi a software commerciali già realizzati per potersi concentrare su altri aspetti quali il miglioramento delle prestazioni, la riduzione dei costi, l'evasione delle tasse... ops, forse questo non dovevo dirlo! ;)
Originariamente inviato da a2000
che fritto misto ! dove lo hai pescato ? :D :D
vero minga.
pensa che Fortran Power Station scrive file binari e strutture dati miste con lo stesso standard del VisualBasic.
questo vuol dire che puoi scambiare informazioni in formato binario senza passare da formattazioni in chiaro. :cool:
:eek: :eek: :eek: downloadabile o no? link,link,link... ;)
Originariamente inviato da cipi
no, non mi dire così.... ciò significherebbe che il mio lavoro è inutile... :cry: :D :D
giusto... ma penso anche che chi DEVE PRODURRE (il che significa che l'azienda pretende un ottimo prodotto in poco tempo) sia spesso costretto ad affidarsi a software commerciali già realizzati per potersi concentrare su altri aspetti quali il miglioramento delle prestazioni, la riduzione dei costi, l'evasione delle tasse... ops, forse questo non dovevo dirlo! ;)
beh, questo si era capito :D :D
se una azienda produce know-how, è licenziataria di qualche prodotto/processo, rifugge per definizione i software commerciali.
i software commerciali vanno bene per le open art quantitative.
Originariamente inviato da cipi
:eek: :eek: :eek: downloadabile o no? link,link,link... ;)
e dalla co' sti link ...
apri un file binario scrivi in fortran e leggi in VB e viceversa.
anche strutture definite ($PACK=2).
cipi ... con 2000 righe di codice si mette su un ottimo:
- simulatore CFD a volumi finiti
- 3D non stazionario
- campi di velocità, pressione, temperatura, composizione
- coordinate cartesiane, cilindriche, sferiche
- termini generativi definiti dall'utente
- modelli di trasporto turbolento
- fluidi non-newtoniani
- fluidi multifase (approccio rigorosamente euleriano per tutte le fasi anche quelle "a particelle" segregate)
- algoritmo intrinsecamente parallelo nested grid con fine grid virtuale ....
- modellatore geometrico e viewer grafico (altre 700 righe).
Originariamente inviato da a2000
cipi ... con 2000 righe di codice si mette su un ottimo:
- simulatore CFD a volumi finiti
- 3D non stazionario
- campi di velocità, pressione, temperatura, composizione
- coordinate cartesiane, cilindriche, sferiche
- termini generativi definiti dall'utente
- modelli di trasporto turbolento
- fluidi non-newtoniani
- fluidi multifase (approccio rigorosamente euleriano per tutte le fasi anche quelle "a particelle" segregate)
- algoritmo intrinsecamente parallelo nested grid con fine grid virtuale ....
- modellatore geometrico e viewer grafico (altre 700 righe).
Premetto che non sono un programmatore ma ho abbastanza cognizione di causa :sofico:
Dipende cosa vuoi simulare... una sfera in una corrente fluida? Forse si, ce la fai... Un profilo alare? Già comincio ad avere i miei dubbi... Una turbomacchina (quindi con domini rotanti) che richiede modelli di turbolenza avanzati (tipo SST) ecc.... beh, se è vero che ci riesci, manda il tuo curriculum qui (http://www-waterloo.ansys.com/cfx/) !!! Intanto se vuoi puoi iscriverti a questo meeting (http://www.congresses.net/modefrontier2004/) così potrai vedere qual'è lo stato dell'arte della simulazione fluidodinamica e dell'ottimizzazione nel mondo... io ci sarò! ;)
oh, se tu ne sei capace, tanto do cappello :ave:
nn voglio mettere in dubbio le tue capacità ma... 2000 righe... mi pare pochetto!
caro cipi ... da buon videogamer dovresti sapere che ci sono tanti "mondi" diversi e che si parlano sempre di meno.
comunque in questo campo, io sono più per i metodi intrinsecamente integrali che per quelli differenziali FEM di derivazione stress analysis ... a meno di non passare a quelli spettrali a sviluppo lungo.
ad ogni modo tra un corso di volo e un altro :rotfl: vedrò di preparare un poster per il castello di miramare ... ah no Jolly Hotel ... pochi soldi eh :D :D
(aspetta la fine dell'anno che te lo passo io un address da 100000 €/y)
Originariamente inviato da a2000
comunque in questo campo, io sono più per i metodi intrinsecamente integrali che per quelli differenziali FEM di derivazione stress analysis ...
:confused: :confused: :confused:
ok se mi parli di metodi alternativi come lattice Boltzmann ma metodi integrali... bah!
Originariamente inviato da cipi
:confused: :confused: :confused:
ok se mi parli di metodi alternativi come lattice Boltzmann ma metodi integrali... bah!
nn ho mai visto un caso pratico trattato con metodi integrali... ne hai mai visto (o fatto) qualcuno tu?
Originariamente inviato da a2000
(aspetta la fine dell'anno che te lo passo io un address da 100000 €/y)
Aspetto, aspetto... :cool: ;) :mano:
Originariamente inviato da cipi
nn ho mai visto un caso pratico trattato con metodi integrali... ne hai mai visto (o fatto) qualcuno tu?
ma guarda che il più famoso codice commerciale CFD usa un metodo integrale !
(per capirci, è quello che viene via in comodato d'uso a circa 30000 € per anno)
Originariamente inviato da a2000
ma guarda che il più famoso codice commerciale CFD usa un metodo integrale !
(per capirci, è quello che viene via in comodato d'uso a circa 30000 € per anno)
quale? :confused:
nome, nome... non fare il timido... :D :D
ma come ? non sei updated allo stato dell'arte ? :confused:
il più famoso e venduto ! :)
non certo quell'applet dell'ansys, quella specie di carrello tenda per ferraioli del flowtran :D
P.S.
naturalmente il mio, pur appartenendo alla stessa famiglia, è meglio. :cool:
diciamo che quello in commercio è la "linea giovane" di quello che si può ottenere con quel "punto di vista" ... :D
lo stesso approccio integrale è quello usato dai più recenti simulatori in campo metereologico as RAMS ...
Originariamente inviato da a2000
il più famoso e venduto ! :)
Ahhhh, ho capito.... FLUENT! Ma quello è anche un volumi finiti... Poi viene Cfx (o prima, non me ne vogliano i distributori!) e anche questo è un volumi finiti!
Quindi? Chi è questa star del rock fluidodinamico? :p
Originariamente inviato da a2000
lo stesso approccio integrale è quello usato dai più recenti simulatori in campo metereologico as RAMS ...
Infatti si vede quanto ci beccano!!! :eheh: :rotfl: :rotfl: :asd:
ci prendono compatibilmente con la natura caotica del problema ... evidentemente. ;)
Originariamente inviato da cipi
Ahhhh, ho capito.... FLUENT! Ma quello è anche un volumi finiti... Poi viene Cfx (o prima, non me ne vogliano i distributori!) e anche questo è un volumi finiti!
Quindi? Chi è questa star del rock fluidodinamico? :p
esatto.
metodo a volumi finiti e quindi integrale.
se il nesso non ti è chiaro considera gli algoritmi nested grid sulle coarse grids.
confermo le 2000 righe. :cool:
ti interessa ? :D
Originariamente inviato da a2000
confermo le 2000 righe. :cool:
ti interessa ? :D
nn penso di potermelo permettere... ;) :sofico:
facciamo così:
prima lo mettiamo in rete (magari open-source) e poi lo vendiamo ... :cool:
e io potrei inserie qualche algoritmo di ottimizzazione che permetta di costruire geometrie efficienti... :cool:
Originariamente inviato da a2000
ok.
attendo pvt.
La mailbox di questo utente è attualmente piena e fino a quando non verrà svuotata non potrà ricevere messaggi privati. Una mail è stata inviata all'utente per notificargli questa situazione.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.