|
From: Steve P. <sj...@gm...> - 2018-11-01 15:25:46
|
Sorry the delay in responding. I'm not sure I understand every aspect of what you want, but here is a suggestion. I would write a new fix, something like fix emit/surf/multi, based on (or derived from) fix emit surf. Define a single surf group which includes all the surfs you want to emit from - that's the group-ID arg to the new fix. Set the type of each surf to a number from 1 to 50+ (no limit), based on which mixture you want each to emit from. Also define 50+ mixtures (no limit, with names like mixmine-N, where N = 1-50. Use "mixmine" or "mixmine-%" as the mix-ID arg to the new fix. Have another keyword like "nmix 50" that you specify for the new fix. That allows the fix to lookup 50 mixture IDs (appending the numeric index or substituing for "%", and store them in an internal list. The new fix loops over all the surfs in the group, uses the type to access the mixture list, and can then emit particles unique to that surf. Depending on how you are partitioning the surf elements into 50 categories, you might not need to use its type to categorize it. E.g. if it's a spatial partitioning, you could loop over surfs, use the center point of the surf to bin it spatially and determine its category index (1-50) on the fly. But using the type flag is more general. If you write this fix, please consider contributing it, and we'd add it to the SPARTA distro. It could be a nice way to do more flexible surface emissions. Steve On Tue, Oct 23, 2018 at 12:33 PM Jacob Schwartz <jsc...@pp...> wrote: > Hi Steve, > > I'm using fix emit/surf. See example snippet below. > I was planning on defining say, 50 mixtures (all of the same species) but > with different temperature and density pairs. > Then I would have 50 surface groups, of which each has several surface > types as members. > I would probably define each surface with its own type, so that I can > reuse the same read_surf data file for many simulations. The group > assignment would be handled programmatically by a script which is writing > this SPARTA input script. > Then, one fix for each surface group would have it emit/surf the > corresponding mixture. > > species mygas.species Li > # densities are computed from temperatures using Ohse formula. > mixture mixture1 Li nrho 1.6745e+21 temp 9.2315e+02 > ... > mixture mixture50 Li nrho 1.0e20 temp 800.0 > > collide vss all mygas.vss > read_surf my_geometry.data > > group surfaceGroup1 surf type 1 2 3 > group surfaceGroup2 surf type 4 5 6 7 > ... > group surfaceGroup50 surf type 71 72 73 > > fix myFix1 emit/surf mixture1 surfaceGroup1 > .... > fix myFix50 emit/surf mixture50 surfaceGroup50 > > I didn't realize that one surface can belong to multiple groups! Reading > the above I initially had a thought of stacking multiple fix emit/surf's on > the same surface such that the total particles and kinetic energy emitted > adds up to the right amount, but that wouldn't help my situation since the > space of Maxwellian distributions is not closed under addition. > > If you want to understand my problem and model better in general: I'm > trying to couple SPARTA with ANSYS in order to model some thin-walled > stainless steel vessels containing liquid and vapor lithium, to determine > the total amount of lithium vapor flow as the containers heat up inside a > vacuum oven. ANSYS would handle thermal conduction and radiation (the > outside of the containers are heated by thermal radiation) and move forward > the model by perhaps 30 seconds or 1 minute at a time. > SPARTA would take as inputs the temperatures of various surface segments > at a given time. I would run SPARTA until it reaches steady state (probably > << 1 second) and output the net evaporation / condensation particle fluxes > at each of the surface segments. Multiplying by latent heat per particle, > can be converted to evaporation / condensation heat fluxes, which then are > added to the corresponding ANSYS surface elements. The heating cycle should > take about 15 minutes, so, about 15-30 back-and-forths between SPARTA and > ANSYS. > > When I saw *fix emit/face/file* command I thought that might do what I > need, but it can only emit on once face of the simulation box and my > geometry is somewhat complicated. > As for writing a new fix, might I start with that one, but have particles > output from arbitrary 2D surfaces? > > Cheers, > Jacob > > On Tue, Oct 23, 2018 at 1:10 PM Steve Plimpton <sj...@gm...> wrote: > >> What command(s) are you using to emit vapors of particles from surface >> elements? >> Is this fix emit/surf or a surface reaction model? If the former, how to >> you get >> a temperature dependence since fix emit/surf doesn't take temperature as >> an input? >> >> The reason surface groups are enumerated in a 32-bit mask is so that one >> surf can belong to multiple groups. >> >> Rather than change that, it would likely be better to create a new fix >> or surface reaction model that worked with a single surface group >> but did something more complex when it emits particles. But I need >> to understand your model better before I can tell you how best to do that. >> >> Steve >> >> On Fri, Oct 19, 2018 at 12:51 PM Jacob Schwartz via sparta-users < >> spa...@li...> wrote: >> >>> Dear SPARTAns, >>> >>> I'm a graduate student using SPARTA for problems related to transport of >>> vapor from evaporating liquids (lithium!). So far I've had success using >>> SPARTA to model situations with surfaces at a few different temperatures. >>> However, vapor pressures are typically steep functions of temperature. >>> >>> I'd like my model to be able to have many surface elements emitting >>> (Maxwellian distributions of) vapors at different temperatures and >>> densities. I'm running into a problem that there are a maximum of 32 >>> surface groups available, so I can specify only 32 temperature+density >>> combinations. If I could even have 64, then I could bin wall temperatures >>> such that amounts of particles emitted there could be within 10% of the >>> 'correct' values. >>> >>> First, is there some better way I might accomplish this with the >>> existing code to approximate more continuous ranges of particle >>> temperatures and densities emitted from surfaces? >>> >>> I could possibly try a dithering scheme (alternating surface elements of >>> group 15 + group 16 looks like a group 15.5) but that could complicate the >>> analysis. It's a fallback option. >>> >>> It looks like the 32 surface group limit is set in surf.h and surf.cpp >>> because various bit masking techniques are used (to quickly figure out what >>> surface a particle has encountered?). Would it be a quick fix to, perhaps, >>> switch to 'long long ints' or something similar? If this bit mask technique >>> is a critical speed optimization, I'd still be satisfied if the code took >>> twice as long to run, but probably not 10x as long. >>> >>> For what it's worth, the models I run are 2D, with less than 1000 lines. >>> >>> Any help in assessing the feasibility of a such a modification would be >>> very much appreciated! >>> >>> Cheers, >>> Jacob Schwartz >>> >>> >>> -- >>> Jacob Schwartz >>> PhD Candidate, Princeton Program in Plasma Physics >>> S206, Princeton Plasma Physics Laboratory >>> 609-243-2659 <%28609%29%20243-2659> >>> _______________________________________________ >>> sparta-users mailing list >>> spa...@li... >>> https://lists.sourceforge.net/lists/listinfo/sparta-users >>> >> > > -- > Jacob Schwartz > PhD Candidate, Princeton Program in Plasma Physics > S206, Princeton Plasma Physics Laboratory > 609-243-2659 <%28609%29%20243-2659> > |