You can subscribe to this list here.
2011 
_{Jan}

_{Feb}
(26) 
_{Mar}
(34) 
_{Apr}
(16) 
_{May}
(15) 
_{Jun}
(22) 
_{Jul}
(17) 
_{Aug}
(14) 
_{Sep}
(9) 
_{Oct}
(10) 
_{Nov}
(17) 
_{Dec}
(6) 

2012 
_{Jan}
(16) 
_{Feb}
(56) 
_{Mar}
(25) 
_{Apr}
(34) 
_{May}
(55) 
_{Jun}
(25) 
_{Jul}
(36) 
_{Aug}
(24) 
_{Sep}
(50) 
_{Oct}
(46) 
_{Nov}
(19) 
_{Dec}
(37) 
2013 
_{Jan}
(33) 
_{Feb}

_{Mar}
(48) 
_{Apr}
(10) 
_{May}
(40) 
_{Jun}
(67) 
_{Jul}
(34) 
_{Aug}
(29) 
_{Sep}
(29) 
_{Oct}
(39) 
_{Nov}
(17) 
_{Dec}
(6) 
2014 
_{Jan}
(36) 
_{Feb}
(14) 
_{Mar}
(63) 
_{Apr}
(16) 
_{May}
(16) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2
(2) 
3
(5) 
4

5

6
(3) 
7
(2) 
8

9

10

11

12

13

14

15

16

17

18

19
(4) 
20

21

22
(2) 
23

24
(4) 
25

26

27

28

29

30



From: Raza Bhatti <softgalaxy.raza@gm...>  20110624 14:45:51

I support this suggestion, may be a tabular format showing EIDORS total references in Conferences, Journals, Patents, etc. Raza. On Fri, Jun 24, 2011 at 4:27 PM, Bill Lionheart <billlionheart@...>wrote: > I wonder if we should look at the number of EIT papers in total, I > would guess that is going up? > > Bill > > On 24 June 2011 11:21, Andy Adler <adler@...> wrote: > > For anyone interested, I've calculated the number of journal papers > > which reference EIDORS to get an idea of how popular it is. I've ignored > > conferences, patents, and theses. Numbers are: > > > > 2011 = 9 > > 2010 = 9 > > 2009 = 8 > > 2008 =19 > > 2007 =12 > > 2006 =13 > > 2005 = 4 > > 2004 = 3 > > 2003 = 4 > > 2002 = 6 > > 2001 = 5 > > > > Comments? I'm a little surprised reduced after 2009, because > > the level of interest seems to be growing. > >  > > Andy Adler <adler@...> +16135202600x8785 > > > > >  > > All the data continuously generated in your IT infrastructure contains a > > definitive record of customers, application performance, security > > threats, fraudulent activity and more. Splunk takes this data and makes > > sense of it. Business sense. IT sense. Common sense.. > > http://p.sf.net/sfu/splunkd2dc1 > > _______________________________________________ > > eidors3dhelp mailing list > > eidors3dhelp@... > > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > > > > >  > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunkd2dc1 > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > 
From: Bill Lionheart <billlionheart@gm...>  20110624 13:27:23

I wonder if we should look at the number of EIT papers in total, I would guess that is going up? Bill On 24 June 2011 11:21, Andy Adler <adler@...> wrote: > For anyone interested, I've calculated the number of journal papers > which reference EIDORS to get an idea of how popular it is. I've ignored > conferences, patents, and theses. Numbers are: > > 2011 = 9 > 2010 = 9 > 2009 = 8 > 2008 =19 > 2007 =12 > 2006 =13 > 2005 = 4 > 2004 = 3 > 2003 = 4 > 2002 = 6 > 2001 = 5 > > Comments? I'm a little surprised reduced after 2009, because > the level of interest seems to be growing. >  > Andy Adler <adler@...> +16135202600x8785 > >  > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunkd2dc1 > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > 
From: Andy Adler <adler@sc...>  20110624 10:21:43

For anyone interested, I've calculated the number of journal papers which reference EIDORS to get an idea of how popular it is. I've ignored conferences, patents, and theses. Numbers are: 2011 = 9 2010 = 9 2009 = 8 2008 =19 2007 =12 2006 =13 2005 = 4 2004 = 3 2003 = 4 2002 = 6 2001 = 5 Comments? I'm a little surprised reduced after 2009, because the level of interest seems to be growing.  Andy Adler <adler@...> +16135202600x8785 
From: Andy Adler <adler@sc...>  20110624 08:58:10

On 22 June 2011 07:17, Nasrin Sultana <nasrin_sultana4@...> wrote: > 1.any reconstruction program needs forward model in eidors website, is it > possible to reconstruct an 3D image from measurement date without using the > theoretical model(mk_common _model)? What is/are the most common/easy > algorithm/s I should go through to understand? I am understanding some > algorithms by trying the the tutorial and example of eidors, will this > approch work? I don't understand the question. 1. You don't need to use mk_common_model (many tutorial examples show this) 2. You do need a model for any inverse problem approach to work. I can't tell you if reading tutorials is a good idea until you tell us what you are trying to do. > 2.as a beginner I am trying to run the tutorial and example of eidors in my > computer. when I try to use netgen, it asks for the path to netgen, netgen > is in 'G:\Program Files\MATLAB\R2010b', but as I give this path, it does not > get it, what can I do? I tried > G:\Progra~1\MATLAB\R2010b\netgen, G:\Progra~1\MATLAB\R2010b, G:/Progra~1/netgen(after > pasting a copy of netgen in program file) etc, but it does not work. I copy > the address of netgen from the properties of netgen folder, so the address > can not be wrong, but is there anything else I should do? The function suggests using '/' with no spaces. Try G:/Progra~1/MATLAB/R2010b/netgen But check where the netgen exe file is.  Andy Adler <adler@...> +16135202600x8785 
From: Andy Adler <adler@sc...>  20110622 09:33:35

On 22 June 2011 07:17, Nasrin Sultana <nasrin_sultana4@...> wrote: > 3. I saw the replies of my previous email on eidors website today, nothing > came to my inbox, is this the system? Nasrin, You should sign up for the mailing list here: https://lists.sourceforge.net/lists/listinfo/eidors3dhelp I'll send answers to the other questions soon.  Andy Adler <adler@...> +16135202600x8785 
From: Nasrin Sultana <nasrin_sultana4@ya...>  20110622 05:17:36

Hi all, Thanks for the previous answers, I am trying all those:) I have some other questions also 1.any reconstruction program needs forward model in eidors website, is it possible to reconstruct an 3D image from measurement date without using the theoretical model(mk_common _model)? What is/are the most common/easy algorithm/s I should go through to understand? I am understanding some algorithms by trying the the tutorial and example of eidors, will this approch work? 2.as a beginner I am trying to run the tutorial and example of eidors in my computer. when I try to use netgen, it asks for the path to netgen, netgen is in 'G:\Program Files\MATLAB\R2010b', but as I give this path, it does not get it, what can I do? I tried G:\Progra~1\MATLAB\R2010b\netgen, G:\Progra~1\MATLAB\R2010b, G:/Progra~1/netgen(after pasting a copy of netgen in program file) etc, but it does not work. I copy the address of netgen from the properties of netgen folder, so the address can not be wrong, but is there anything else I should do? 3. I saw the replies of my previous email on eidors website today, nothing came to my inbox, is this the system? many many thanks for your time and patience for a beginner, I really appreciate this regards, Nasrin 
From: Andy Adler <adler@sc...>  20110619 18:24:50

Dear EIDORS contributors, This weekend, I've been visiting Dominique Gibert in Rennes, France and we've been working on using EIDORS for geophysical EIT data. We've had some successes, but there are a few bugs which will need to be worked out. The main requirement will be to add a solver which works on log conductivity, since rock conductivities vary significantly. For now, we've begun to put geophysical data into the data repository. Here is a sample from Pont Pean (an old mine which is a few 100m from Dominique's house). eidors3d.sf.net/data_contrib/dg_geophysical_EIT/pont_pean.shtml We will be adding more data and tutorials to use the data soon.  Andy Adler <adler@...> +16135202600x8785 
From: Bill Lionheart <billlionheart@gm...>  20110619 10:22:42

As well as reading the FAQ http://eidors3d.sourceforge.net/faq.shtml people like Nasrin new to EIT reconstruction might find it helpful to look at the lectures we recorded http://eitrecon.blogspot.com/ Bill On 19 June 2011 09:24, Andy Adler <adler@...> wrote: > On 19 June 2011 10:06, Nasrin Sultana <nasrin_sultana4@...> wrote: >> I am trying to work on EIT, but I am at the very first step. Can anyone tell >> me how can I proceed to get an image that is constructed (/reconstructed?) >> from any EIT data? > > See EIDORS tutorials. > >> As a novice I am even confused how to present the >> question. So far I have seen, there are several algorithms, how can I know >> about these? > > Read EIT papers. > >> any website? > > eidors.org > >> how can I use eidors here? > > By following the tutorials. eidors.org/tutorial > >> I can't understand the >> programs, may be I am too early? > > Maybe. >  > Andy Adler <adler@...> +16135202600x8785 > >  > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephoxdev2dev > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > 
From: Andy Adler <adler@sc...>  20110619 08:24:43

On 19 June 2011 10:06, Nasrin Sultana <nasrin_sultana4@...> wrote: > I am trying to work on EIT, but I am at the very first step. Can anyone tell > me how can I proceed to get an image that is constructed (/reconstructed?) > from any EIT data? See EIDORS tutorials. > As a novice I am even confused how to present the > question. So far I have seen, there are several algorithms, how can I know > about these? Read EIT papers. > any website? eidors.org > how can I use eidors here? By following the tutorials. eidors.org/tutorial > I can't understand the > programs, may be I am too early? Maybe.  Andy Adler <adler@...> +16135202600x8785 
From: Nasrin Sultana <nasrin_sultana4@ya...>  20110619 08:06:39

Hi all, I am trying to work on EIT, but I am at the very first step. Can anyone tell me how can I proceed to get an image that is constructed (/reconstructed?) from any EIT data? As a novice I am even confused how to present the question. So far I have seen, there are several algorithms, how can I know about these? any website? how can I use eidors here? I can't understand the programs, may be I am too early? please advice me.. Thanks in advance and regards, Nasrin 
From: Andy Adler <adler@sc...>  20110607 13:37:48

Hi Michael, Eventually, it would be nice to have all sorts of electrode models, point, complete, shunt, etc. However, it isn't reasonable to ask all fwd solvers to accept all electrode types. I think the easiest is to just implement what you can at this point (ie. no mixed models). And then have your code give an error if it is given electrodes it can't handle. (I've rarely used mixed models. The only case was to put electrodes within a body, for which the other eidors code can only manage point electrodes) Thanks  Andy Adler <adler@...> +16135202600x8785 On 7 June 2011 06:44, Michael Crabb <Michael.Crabb@...> wrote: > Dear Andy, > > I was just wondering if eidors is capable of mixing point and complete > electrodes on a single model? I am attempting to clear up some code at the > moment that makes computing the system matrix independent of the electrode > model and outputs an index matrix of the electrode positions, which can be > used later to find voltage data on the electrodes. > > If there was NO mixing of electrode models, I could just tested the first > electrode, and if this is only 1 node, I could call this a point electrode > model, and if not, a complete electrode model, and then the index matrix > would be relatively easy to compute for the model. > > It seems that mixing a point and complete electrode model would be a more > difficult task, especially in computing the various matrices and assembling > into the total system matrix (and I don't know if this has an practical > use..?). For the time being anyway, I am going to do no mixing, as this > easier, but it would be good to know if mixing would be useful in the > future? Any comments or suggestions on this would be appreciated. > > Also, do you think it is worth implementing a shunt model at all? It doesn't > seem that this model really serves an practical importance at the moment? > > Regards, > > Michael Crabb > >  > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephoxdev2dev > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > > 
From: Michael Crabb <Michael.C<rabb@po...>  20110607 10:44:56

Dear Andy, I was just wondering if eidors is capable of mixing point and complete electrodes on a single model? I am attempting to clear up some code at the moment that makes computing the system matrix independent of the electrode model and outputs an index matrix of the electrode positions, which can be used later to find voltage data on the electrodes. If there was NO mixing of electrode models, I could just tested the first electrode, and if this is only 1 node, I could call this a point electrode model, and if not, a complete electrode model, and then the index matrix would be relatively easy to compute for the model. It seems that mixing a point and complete electrode model would be a more difficult task, especially in computing the various matrices and assembling into the total system matrix (and I don't know if this has an practical use..?). For the time being anyway, I am going to do no mixing, as this easier, but it would be good to know if mixing would be useful in the future? Any comments or suggestions on this would be appreciated. Also, do you think it is worth implementing a shunt model at all? It doesn't seem that this model really serves an practical importance at the moment? Regards, Michael Crabb 
From: Andy Adler <adler@sc...>  20110606 16:22:35

Bartek, I think we do need a TSVD solver. Don't worry about "solver inflation". It's ok if it's a wrapper. It should accept a hyperparameter option. This could perhaps be interpreted as the ratio between the first singular value and the maximum one we keep.  Andy Adler <adler@...> +16135202600x8785 On 6 June 2011 11:28, Bartek Grychtol <b.grychtol@...> wrote: > Hi All, > > I need a TSVD solver and couldn't find any in EIDORS (?), so I'm > thinking of implementing one. > In general there are two ways round it, but I don't think we have a > consensus. Should it be: > 1. a solver, inv_TSVD > OR > 2. just an RM calculator calc_TSVD_RM > > The advantage of the solver approach is that it could use options like > imdl.hyperparameter.value and consequently be compatible with functions > like choose_noise_figure or calc_noise_figure. However, it's de facto > just a wrapper for solve_use_RM, so it would be a bit of a solver > inflation. > > As a background, for the GREIT algorithm we have calc_GREIT_RM and > mk_GREIT_model, where the latter reimplements the functionality of > choose_noise_figure, which in retrospect seems like a bit of a waste. > > What do you think? > > Best wishes, > > Bartek > >  > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/questdev2dev2 > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > 
From: Bill Lionheart <billlionheart@gm...>  20110606 15:54:58

It should be a solver. I like the idea of using the hyper parameter to determine the truncation level in a way that makes it compatible with Tikhonov Have you considered using TGSVD though? Bill On 06/06/11 16:28, Bartek Grychtol wrote: > Hi All, > > I need a TSVD solver and couldn't find any in EIDORS (?), so I'm > thinking of implementing one. > In general there are two ways round it, but I don't think we have a > consensus. Should it be: > 1. a solver, inv_TSVD > OR > 2. just an RM calculator calc_TSVD_RM > > The advantage of the solver approach is that it could use options like > imdl.hyperparameter.value and consequently be compatible with functions > like choose_noise_figure or calc_noise_figure. However, it's de facto > just a wrapper for solve_use_RM, so it would be a bit of a solver > inflation. > > As a background, for the GREIT algorithm we have calc_GREIT_RM and > mk_GREIT_model, where the latter reimplements the functionality of > choose_noise_figure, which in retrospect seems like a bit of a waste. > > What do you think? > > Best wishes, > > Bartek > >  > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/questdev2dev2 > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp 
From: Bartek Grychtol <b.grychtol@gm...>  20110606 15:28:23

Hi All, I need a TSVD solver and couldn't find any in EIDORS (?), so I'm thinking of implementing one. In general there are two ways round it, but I don't think we have a consensus. Should it be: 1. a solver, inv_TSVD OR 2. just an RM calculator calc_TSVD_RM The advantage of the solver approach is that it could use options like imdl.hyperparameter.value and consequently be compatible with functions like choose_noise_figure or calc_noise_figure. However, it's de facto just a wrapper for solve_use_RM, so it would be a bit of a solver inflation. As a background, for the GREIT algorithm we have calc_GREIT_RM and mk_GREIT_model, where the latter reimplements the functionality of choose_noise_figure, which in retrospect seems like a bit of a waste. What do you think? Best wishes, Bartek 
From: Andy Adler <adler@sc...>  20110603 15:44:55

Hi Russel and Bartek, I agree with this. Let's add mat_idx and fc to the models that come out of the ng*models functions. Now we need to decide what to call them: How about material_idx, and boundary_numbers Russell, do you have svn commit priveledges?  Andy Adler <adler@...> +16135202600x8785 On 3 June 2011 06:27, Russell Miller <russell.miller@...> wrote: > Hi Bartek, > > This sounds good. We would also need to add fc as an output argument to any > function that calls ng_mk_fwd_model (I have actually been calling > ng_mk_gen_models to create my finite forward model). > > Best, > > Russell > > > On Friday 03 Jun 2011 11:20:57 Bartek Grychtol wrote: >> Hi All, >> >> Once we're discussing ng_mk_fwd_model it's worth having a look at the >> mat_indices too. At the moment, the signature is >> >> [fwd_mdl, mat_indices] = ng_mk_fwd_model(...); >> >> But if there is more than one material in the model, it makes sense to >> put them into fwd_mdl.mat_idx and this is what the recent mk_GREIT_model >> function does. >> I presume the original argument for not doing it this way was not to >> inflate the size of the fmdl structure unnecessary. (But what about >> conditional inclusion?) >> >> Following the same argument, we should only put the face numbers in the >> fmdl if they are useful, so I think the best way would be for >> ng_mk_fwd_model to pass 'fc' out as an output (like mat_indices is now) >> and to request and handle them as needed in the calling functions. >> >> On the other hand, mat_indices are always useful if there's more than >> one material, so I would advocate including them in the fmdl structure >> in that case, but we would probably have to keep it in the output as >> well to avoid breaking a lot of code. >> >> Best, >> >> Bartek >> >> On 03/06/2011 12:01, Russell Miller wrote: >> > Hi Andy, >> > >> > I don't think my last post was clear, sorry. As far as I am aware, >> > netgen does not have infinite elements but I have been working on some >> > code that adds them to a simple EIDORS forward model after the simple >> > model has been meshed by netgen. >> > >> > The main problem is defining which boundaries need the infinite >> > elements (i.e. for a halfspace this would be all boundaries except >> > the top surface). I think the best way to define which boundaries need >> > infinite elements is to have a number for each boundary (or >> > face/surface) and then the modeller can choose which faces require >> > infinite elements (I am also in the process of writing a function that >> > builds a halfspace model using netgen then automatically adds >> > infinite elements on the correct faces). >> > >> > Fortunately, I have found that netgen numbers the surfaces of a given >> > object and these are the numbers that are stored in the variable "fc" >> > in construct_fwd_model. I just need this variable fc to be assigned as >> > a field of the fwd_model structure in the mg_mk_fwd_model function so >> > that when I build my initial (finite) model using ng_mk_gen_models I >> > can then append infinite elements to the correct boundaries. >> > >> > I have made a local copy of ng_mk_fwd_model.m in which I have added to >> > the following lines (additions in bold): >> > >> > [srf,vtx,fc,bc,simp,edg,mat_ind] = ng_read_mesh(ng_vol_filename); >> > >> > ... >> > >> > fwd_mdl= construct_fwd_model(srf,vtx,simp,bc, name, ... >> > >> > stim_pattern, centres, z_contact,fc); >> > >> > ... >> > >> > mdl.nodes = vtx; >> > >> > mdl.elems = simp; >> > >> > mdl.boundary = srf; >> > >> > mdl.boundary_numbers = fc; >> > >> > mdl.gnd_node= find_centre_node(vtx); >> > >> > mdl.np_fwd_solve.perm_sym = '{n}'; >> > >> > mdl.name = name; >> > >> > ... >> > >> > My question is: can you add these same lines of code to the svn >> > version of EIDORS so that I can access the surface numbers in order to >> > append the infinite elements to the correct surfaces? Adding an extra >> > field to the fwd_model structure shouldn't cause any bugs in existing >> > code if the field has never been used before. >> > >> > Thanks, >> > >> > Russell >> > >> > Hi Russell, >> > I didn't even know that netgen does infinite elements. To start us off >> > discussing how to do it, could you send an example (ie. a netgen geo >> > file that makes infinite elements). >> > This is definitely useful stuff. We just need to figure out how to >> > do it most easily, without breaking older code. >> > Thanks >> >  >> > Andy Adler <adler@...> +16135202600x8785 >> > On 2 June 2011 07:47, Russell Miller >> > >> > <russell.miller@...> wrote: >> > > Hi Andy, >> > > >> > > I've been working code to introduce infinite elements to solve forward >> > > problems in halfspace domains. I think the best way to choose on which >> > > boundary faces I need to "append" the infinite elements is to have the >> > > face numbers (or surfnr) as they are called in the NETGEN .vol output >> > > files. I have noticed that the function ng_read_mesh.m does get these >> > > values and stores them in a variable called fc but then >> > > ng_mk_fwd_model does not pass these values to construct_fwd_model. >> > > >> > > Basically, my question is: Can we modify ng_mk_fwd_model so that the >> > > fwd_model structure has a field that store the face numbers so that >> > > they can be cross referenced with the fwd_model.boundary field? >> > > >> > > Best regards, >> > > >> > > Russell Miller >> > >> >  >> >  Simplify data backup and recovery for your virtual environment with >> > vRanger. Installation's a snap, and flexible recovery options mean your >> > data is safe, secure and there when you need it. Discover what all the >> > cheering's about. Get your free trial download today. >> > http://p.sf.net/sfu/questdev2dev2 >> > >> > >> > _______________________________________________ >> > eidors3dhelp mailing list >> > eidors3dhelp@... >> > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > >  > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/questdev2dev2 > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > 
From: Russell Miller <russell.miller@ma...>  20110603 10:30:31

Hi Bartek, This sounds good. We would also need to add fc as an output argument to any function that calls ng_mk_fwd_model (I have actually been calling ng_mk_gen_models to create my finite forward model). Best, Russell On Friday 03 Jun 2011 11:20:57 Bartek Grychtol wrote: > Hi All, > > Once we're discussing ng_mk_fwd_model it's worth having a look at the > mat_indices too. At the moment, the signature is > > [fwd_mdl, mat_indices] = ng_mk_fwd_model(...); > > But if there is more than one material in the model, it makes sense to > put them into fwd_mdl.mat_idx and this is what the recent mk_GREIT_model > function does. > I presume the original argument for not doing it this way was not to > inflate the size of the fmdl structure unnecessary. (But what about > conditional inclusion?) > > Following the same argument, we should only put the face numbers in the > fmdl if they are useful, so I think the best way would be for > ng_mk_fwd_model to pass 'fc' out as an output (like mat_indices is now) > and to request and handle them as needed in the calling functions. > > On the other hand, mat_indices are always useful if there's more than > one material, so I would advocate including them in the fmdl structure > in that case, but we would probably have to keep it in the output as > well to avoid breaking a lot of code. > > Best, > > Bartek > > On 03/06/2011 12:01, Russell Miller wrote: > > Hi Andy, > > > > I don't think my last post was clear, sorry. As far as I am aware, > > netgen does not have infinite elements but I have been working on some > > code that adds them to a simple EIDORS forward model after the simple > > model has been meshed by netgen. > > > > The main problem is defining which boundaries need the infinite > > elements (i.e. for a halfspace this would be all boundaries except > > the top surface). I think the best way to define which boundaries need > > infinite elements is to have a number for each boundary (or > > face/surface) and then the modeller can choose which faces require > > infinite elements (I am also in the process of writing a function that > > builds a halfspace model using netgen then automatically adds > > infinite elements on the correct faces). > > > > Fortunately, I have found that netgen numbers the surfaces of a given > > object and these are the numbers that are stored in the variable "fc" > > in construct_fwd_model. I just need this variable fc to be assigned as > > a field of the fwd_model structure in the mg_mk_fwd_model function so > > that when I build my initial (finite) model using ng_mk_gen_models I > > can then append infinite elements to the correct boundaries. > > > > I have made a local copy of ng_mk_fwd_model.m in which I have added to > > the following lines (additions in bold): > > > > [srf,vtx,fc,bc,simp,edg,mat_ind] = ng_read_mesh(ng_vol_filename); > > > > ... > > > > fwd_mdl= construct_fwd_model(srf,vtx,simp,bc, name, ... > > > > stim_pattern, centres, z_contact,fc); > > > > ... > > > > mdl.nodes = vtx; > > > > mdl.elems = simp; > > > > mdl.boundary = srf; > > > > mdl.boundary_numbers = fc; > > > > mdl.gnd_node= find_centre_node(vtx); > > > > mdl.np_fwd_solve.perm_sym = '{n}'; > > > > mdl.name = name; > > > > ... > > > > My question is: can you add these same lines of code to the svn > > version of EIDORS so that I can access the surface numbers in order to > > append the infinite elements to the correct surfaces? Adding an extra > > field to the fwd_model structure shouldn't cause any bugs in existing > > code if the field has never been used before. > > > > Thanks, > > > > Russell > > > > Hi Russell, > > I didn't even know that netgen does infinite elements. To start us off > > discussing how to do it, could you send an example (ie. a netgen geo > > file that makes infinite elements). > > This is definitely useful stuff. We just need to figure out how to > > do it most easily, without breaking older code. > > Thanks > >  > > Andy Adler <adler@...> +16135202600x8785 > > On 2 June 2011 07:47, Russell Miller > > > > <russell.miller@...> wrote: > > > Hi Andy, > > > > > > I've been working code to introduce infinite elements to solve forward > > > problems in halfspace domains. I think the best way to choose on which > > > boundary faces I need to "append" the infinite elements is to have the > > > face numbers (or surfnr) as they are called in the NETGEN .vol output > > > files. I have noticed that the function ng_read_mesh.m does get these > > > values and stores them in a variable called fc but then > > > ng_mk_fwd_model does not pass these values to construct_fwd_model. > > > > > > Basically, my question is: Can we modify ng_mk_fwd_model so that the > > > fwd_model structure has a field that store the face numbers so that > > > they can be cross referenced with the fwd_model.boundary field? > > > > > > Best regards, > > > > > > Russell Miller > > > >  > >  Simplify data backup and recovery for your virtual environment with > > vRanger. Installation's a snap, and flexible recovery options mean your > > data is safe, secure and there when you need it. Discover what all the > > cheering's about. Get your free trial download today. > > http://p.sf.net/sfu/questdev2dev2 > > > > > > _______________________________________________ > > eidors3dhelp mailing list > > eidors3dhelp@... > > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp 
From: Bill Lionheart <bill.lionheart@ma...>  20110603 10:28:01

I think the point is that you add infinite elements to faces of a FEM mesh so all you need is to keep track of faces. Passing fc might be useful anyway, but it just has to be an optional field as other mesh generators might not provide it. Maybe Russell should just register as a dev then he can commit his version to subversion. It seems to it is not going to break anything. Is boundary numbers a good name? Bill On 03/06/11 11:01, Russell Miller wrote: > > Hi Andy, > > I don't think my last post was clear, sorry. As far as I am aware, > netgen does not have infinite elements but I have been working on some > code that adds them to a simple EIDORS forward model after the simple > model has been meshed by netgen. > > The main problem is defining which boundaries need the infinite > elements (i.e. for a halfspace this would be all boundaries except > the top surface). I think the best way to define which boundaries need > infinite elements is to have a number for each boundary (or > face/surface) and then the modeller can choose which faces require > infinite elements (I am also in the process of writing a function that > builds a halfspace model using netgen then automatically adds > infinite elements on the correct faces). > > Fortunately, I have found that netgen numbers the surfaces of a given > object and these are the numbers that are stored in the variable "fc" > in construct_fwd_model. I just need this variable fc to be assigned as > a field of the fwd_model structure in the mg_mk_fwd_model function so > that when I build my initial (finite) model using ng_mk_gen_models I > can then append infinite elements to the correct boundaries. > > I have made a local copy of ng_mk_fwd_model.m in which I have added to > the following lines (additions in bold): > > [srf,vtx,fc,bc,simp,edg,mat_ind] = ng_read_mesh(ng_vol_filename); > > ... > > fwd_mdl= construct_fwd_model(srf,vtx,simp,bc, name, ... > > stim_pattern, centres, z_contact,fc); > > ... > > mdl.nodes = vtx; > > mdl.elems = simp; > > mdl.boundary = srf; > > mdl.boundary_numbers = fc; > > mdl.gnd_node= find_centre_node(vtx); > > mdl.np_fwd_solve.perm_sym = '{n}'; > > mdl.name = name; > > ... > > My question is: can you add these same lines of code to the svn > version of EIDORS so that I can access the surface numbers in order to > append the infinite elements to the correct surfaces? Adding an extra > field to the fwd_model structure shouldn't cause any bugs in existing > code if the field has never been used before. > > Thanks, > > Russell > > Hi Russell, > I didn't even know that netgen does infinite elements. To start us off > discussing how to do it, could you send an example (ie. a netgen geo > file that makes infinite elements). > This is definitely useful stuff. We just need to figure out how to > do it most easily, without breaking older code. > Thanks >  > Andy Adler<adler@...> +16135202600x8785 > On 2 June 2011 07:47, Russell Miller > <russell.miller@...> wrote: > > Hi Andy, > > > > I've been working code to introduce infinite elements to solve forward > > problems in halfspace domains. I think the best way to choose on which > > boundary faces I need to "append" the infinite elements is to have the face > > numbers (or surfnr) as they are called in the NETGEN .vol output files. I have > > noticed that the function ng_read_mesh.m does get these values and stores them > > in a variable called fc but then ng_mk_fwd_model does not pass these values to > > construct_fwd_model. > > > > Basically, my question is: Can we modify ng_mk_fwd_model so that the fwd_model > > structure has a field that store the face numbers so that they can be cross > > referenced with the fwd_model.boundary field? > > > > Best regards, > > > > Russell Miller  Bill Lionheart, Professor of Applied Mathematics, University of Manchester http://www.maths.manchester.ac.uk/~bl tel:+44 161 306 8978 Office: 1.126 Alan Turing Building 
From: Bartek Grychtol <b.grychtol@gm...>  20110603 10:21:19

Hi All, Once we're discussing ng_mk_fwd_model it's worth having a look at the mat_indices too. At the moment, the signature is [fwd_mdl, mat_indices] = ng_mk_fwd_model(...); But if there is more than one material in the model, it makes sense to put them into fwd_mdl.mat_idx and this is what the recent mk_GREIT_model function does. I presume the original argument for not doing it this way was not to inflate the size of the fmdl structure unnecessary. (But what about conditional inclusion?) Following the same argument, we should only put the face numbers in the fmdl if they are useful, so I think the best way would be for ng_mk_fwd_model to pass 'fc' out as an output (like mat_indices is now) and to request and handle them as needed in the calling functions. On the other hand, mat_indices are always useful if there's more than one material, so I would advocate including them in the fmdl structure in that case, but we would probably have to keep it in the output as well to avoid breaking a lot of code. Best, Bartek On 03/06/2011 12:01, Russell Miller wrote: > > Hi Andy, > > I don't think my last post was clear, sorry. As far as I am aware, > netgen does not have infinite elements but I have been working on some > code that adds them to a simple EIDORS forward model after the simple > model has been meshed by netgen. > > The main problem is defining which boundaries need the infinite > elements (i.e. for a halfspace this would be all boundaries except > the top surface). I think the best way to define which boundaries need > infinite elements is to have a number for each boundary (or > face/surface) and then the modeller can choose which faces require > infinite elements (I am also in the process of writing a function that > builds a halfspace model using netgen then automatically adds > infinite elements on the correct faces). > > Fortunately, I have found that netgen numbers the surfaces of a given > object and these are the numbers that are stored in the variable "fc" > in construct_fwd_model. I just need this variable fc to be assigned as > a field of the fwd_model structure in the mg_mk_fwd_model function so > that when I build my initial (finite) model using ng_mk_gen_models I > can then append infinite elements to the correct boundaries. > > I have made a local copy of ng_mk_fwd_model.m in which I have added to > the following lines (additions in bold): > > [srf,vtx,fc,bc,simp,edg,mat_ind] = ng_read_mesh(ng_vol_filename); > > ... > > fwd_mdl= construct_fwd_model(srf,vtx,simp,bc, name, ... > > stim_pattern, centres, z_contact,fc); > > ... > > mdl.nodes = vtx; > > mdl.elems = simp; > > mdl.boundary = srf; > > mdl.boundary_numbers = fc; > > mdl.gnd_node= find_centre_node(vtx); > > mdl.np_fwd_solve.perm_sym = '{n}'; > > mdl.name = name; > > ... > > My question is: can you add these same lines of code to the svn > version of EIDORS so that I can access the surface numbers in order to > append the infinite elements to the correct surfaces? Adding an extra > field to the fwd_model structure shouldn't cause any bugs in existing > code if the field has never been used before. > > Thanks, > > Russell > > Hi Russell, > I didn't even know that netgen does infinite elements. To start us off > discussing how to do it, could you send an example (ie. a netgen geo > file that makes infinite elements). > This is definitely useful stuff. We just need to figure out how to > do it most easily, without breaking older code. > Thanks >  > Andy Adler <adler@...> +16135202600x8785 > On 2 June 2011 07:47, Russell Miller > <russell.miller@...> wrote: > > Hi Andy, > > > > I've been working code to introduce infinite elements to solve forward > > problems in halfspace domains. I think the best way to choose on which > > boundary faces I need to "append" the infinite elements is to have the face > > numbers (or surfnr) as they are called in the NETGEN .vol output files. I have > > noticed that the function ng_read_mesh.m does get these values and stores them > > in a variable called fc but then ng_mk_fwd_model does not pass these values to > > construct_fwd_model. > > > > Basically, my question is: Can we modify ng_mk_fwd_model so that the fwd_model > > structure has a field that store the face numbers so that they can be cross > > referenced with the fwd_model.boundary field? > > > > Best regards, > > > > Russell Miller > > >  > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Discover what all the cheering's about. > Get your free trial download today. > http://p.sf.net/sfu/questdev2dev2 > > > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp 
From: Russell Miller <russell.miller@ma...>  20110603 10:04:58

Hi Andy, I don't think my last post was clear, sorry. As far as I am aware, netgen does not have infinite elements but I have been working on some code that adds them to a simple EIDORS forward model after the simple model has been meshed by netgen. The main problem is defining which boundaries need the infinite elements (i.e. for a halfspace this would be all boundaries except the top surface). I think the best way to define which boundaries need infinite elements is to have a number for each boundary (or face/surface) and then the modeller can choose which faces require infinite elements (I am also in the process of writing a function that builds a halfspace model using netgen then automatically adds infinite elements on the correct faces). Fortunately, I have found that netgen numbers the surfaces of a given object and these are the numbers that are stored in the variable "fc" in construct_fwd_model. I just need this variable fc to be assigned as a field of the fwd_model structure in the mg_mk_fwd_model function so that when I build my initial (finite) model using ng_mk_gen_models I can then append infinite elements to the correct boundaries. I have made a local copy of ng_mk_fwd_model.m in which I have added to the following lines (additions in bold): [srf,vtx,fc,bc,simp,edg,mat_ind] = ng_read_mesh(ng_vol_filename); ... fwd_mdl= construct_fwd_model(srf,vtx,simp,bc, name, ... stim_pattern, centres, z_contact,fc); ... mdl.nodes = vtx; mdl.elems = simp; mdl.boundary = srf; mdl.boundary_numbers = fc; mdl.gnd_node= find_centre_node(vtx); mdl.np_fwd_solve.perm_sym = '{n}'; mdl.name = name; ... My question is: can you add these same lines of code to the svn version of EIDORS so that I can access the surface numbers in order to append the infinite elements to the correct surfaces? Adding an extra field to the fwd_model structure shouldn't cause any bugs in existing code if the field has never been used before. Thanks, Russell Hi Russell, I didn't even know that netgen does infinite elements. To start us off discussing how to do it, could you send an example (ie. a netgen geo file that makes infinite elements). This is definitely useful stuff. We just need to figure out how to do it most easily, without breaking older code. Thanks  Andy Adler <adler@...> +16135202600x8785 On 2 June 2011 07:47, Russell Miller <russell.miller@...> wrote: > Hi Andy, > > I've been working code to introduce infinite elements to solve forward > problems in halfspace domains. I think the best way to choose on which > boundary faces I need to "append" the infinite elements is to have the face > numbers (or surfnr) as they are called in the NETGEN .vol output files. I have > noticed that the function ng_read_mesh.m does get these values and stores them > in a variable called fc but then ng_mk_fwd_model does not pass these values to > construct_fwd_model. > > Basically, my question is: Can we modify ng_mk_fwd_model so that the fwd_model > structure has a field that store the face numbers so that they can be cross > referenced with the fwd_model.boundary field? > > Best regards, > > Russell Miller 
From: Andy Adler <adler@sc...>  20110602 14:47:05

Hi Russell, I didn't even know that netgen does infinite elements. To start us off discussing how to do it, could you send an example (ie. a netgen geo file that makes infinite elements). This is definitely useful stuff. We just need to figure out how to do it most easily, without breaking older code. Thanks  Andy Adler <adler@...> +16135202600x8785 On 2 June 2011 07:47, Russell Miller <russell.miller@...> wrote: > Hi Andy, > > I've been working code to introduce infinite elements to solve forward > problems in halfspace domains. I think the best way to choose on which > boundary faces I need to "append" the infinite elements is to have the face > numbers (or surfnr) as they are called in the NETGEN .vol output files. I have > noticed that the function ng_read_mesh.m does get these values and stores them > in a variable called fc but then ng_mk_fwd_model does not pass these values to > construct_fwd_model. > > Basically, my question is: Can we modify ng_mk_fwd_model so that the fwd_model > structure has a field that store the face numbers so that they can be cross > referenced with the fwd_model.boundary field? > > Best regards, > > Russell Miller > >  > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope  It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/questsfdev2dev > _______________________________________________ > eidors3dhelp mailing list > eidors3dhelp@... > https://lists.sourceforge.net/lists/listinfo/eidors3dhelp > 
From: Russell Miller <russell.miller@ma...>  20110602 12:08:04

Hi Andy, I've been working code to introduce infinite elements to solve forward problems in halfspace domains. I think the best way to choose on which boundary faces I need to "append" the infinite elements is to have the face numbers (or surfnr) as they are called in the NETGEN .vol output files. I have noticed that the function ng_read_mesh.m does get these values and stores them in a variable called fc but then ng_mk_fwd_model does not pass these values to construct_fwd_model. Basically, my question is: Can we modify ng_mk_fwd_model so that the fwd_model structure has a field that store the face numbers so that they can be cross referenced with the fwd_model.boundary field? Best regards, Russell Miller 