casa  $Rev:20696$
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Defines
ComponentModels.h
Go to the documentation of this file.
00001 //# ComponentModels.h: classes that define a functional representation of the sky brightness
00002 //# Copyright (C) 1999,2000
00003 //# Associated Universities, Inc. Washington DC, USA.
00004 //#
00005 //# This library is free software; you can redistribute it and/or modify it
00006 //# under the terms of the GNU Library General Public License as published by
00007 //# the Free Software Foundation; either version 2 of the License, or (at your
00008 //# option) any later version.
00009 //#
00010 //# This library is distributed in the hope that it will be useful, but WITHOUT
00011 //# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
00012 //# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Library General Public
00013 //# License for more details.
00014 //#
00015 //# You should have received a copy of the GNU Library General Public License
00016 //# along with this library; if not, write to the Free Software Foundation,
00017 //# Inc., 675 Massachusetts Ave, Cambridge, MA 02139, USA.
00018 //#
00019 //# Correspondence concerning AIPS++ should be addressed as follows:
00020 //#        Internet email: aips2-request@nrao.edu.
00021 //#        Postal address: AIPS++ Project Office
00022 //#                        National Radio Astronomy Observatory
00023 //#                        520 Edgemont Road
00024 //#                        Charlottesville, VA 22903-2475 USA
00025 //#
00026 //# $Id: ComponentModels.h 20691 2009-07-14 03:13:54Z Malte.Marquarding $
00027 
00028 #ifndef COMPONENTS_COMPONENTMODELS_H
00029 #define COMPONENTS_COMPONENTMODELS_H
00030 
00031 #include <components/ComponentModels/ComponentType.h>
00032 
00033 #include <components/ComponentModels/Flux.h>
00034 
00035 #include <components/ComponentModels/ComponentShape.h>
00036 #include <components/ComponentModels/TwoSidedShape.h>
00037 #include <components/ComponentModels/PointShape.h>
00038 #include <components/ComponentModels/GaussianShape.h>
00039 #include <components/ComponentModels/DiskShape.h>
00040 
00041 #include <components/ComponentModels/SpectralModel.h>
00042 #include <components/ComponentModels/ConstantSpectrum.h>
00043 #include <components/ComponentModels/SpectralIndex.h>
00044 
00045 #include <components/ComponentModels/SkyCompBase.h>
00046 #include <components/ComponentModels/SkyCompRep.h>
00047 #include <components/ComponentModels/SkyComponent.h>
00048 
00049 #include <components/ComponentModels/ComponentList.h>
00050 #include <trial/ComponentModels/DOcomponentlist.h>
00051 
00052 namespace casa { //# NAMESPACE CASA - BEGIN
00053 
00054 // <module>
00055 //
00056 // <summary>classes that define a functional representation of the sky brightness</summary>
00057 
00058 // <prerequisite>
00059 //   <li> Measures
00060 // </prerequisite>
00061 //
00062 
00063 // <reviewed reviewer="" date="yyyy/mm/dd" demos="">
00064 // </reviewed>
00065 
00066 // <etymology>
00067 //#! Except when it is obvious (e.g., "Arrays") explain how the module name
00068 //#! expresses the role of this module.  Example: IPosition is short for
00069 //#! "Integral Position" - a specialized integer vector for specifying
00070 //#! array dimensions and indices.
00071 // </etymology>
00072 //
00073 // <synopsis>
00074 
00075 // This module contains classes which parameterise emmision from the sky using
00076 // relatively simple functions. 
00077 
00078 //#! What does the module do?  How?  For whom?   This should include code
00079 //#! fragments as appropriate to support text. Code fragments shall be
00080 //#! delimited by <srcblock> </srcblock> tags.  The synopsis section will
00081 //#! usually be dozens of lines long.
00082 // </synopsis>
00083 //
00084 // <example>
00085 //#! One to many concise (~10-40 lines) examples, with a modest amount of
00086 //#! text to support code fragments.   Use <srcblock> and </srcblock> to
00087 //#! delimit example code.
00088 // </example>
00089 //
00090 // <motivation>
00091 //#! Insight into a module is often provided by a description of the
00092 //#! circumstances that led to its conception and design.  Describe
00093 //#! them here.
00094 // </motivation>
00095 
00096 // <todo asof="yyyy/mm/dd">
00097 //#! A List of bugs, limitations, extensions or planned refinements.
00098 //#! The programmer should fill in a date in the "asof" field, which
00099 //#! will usually be the date at which the class is submitted for review.
00100 //#! If, during the review, new "todo" items come up, then the "asof"
00101 //#! date should be changed to the end of the review period.
00102 //   <li> add this feature
00103 //   <li> fix this bug
00104 //   <li> discuss possible extension
00105 // </todo>
00106 
00107 //#! The module header file can be a big convenience to client programmers,
00108 //#! because it allows them to use classes without studying them closely.
00109 //#! But you -- the author of the module -- may want to notify the client
00110 //#! programmer of some of the circumstances in which they *should* look
00111 //#! more deeply, and get some understanding of the individual classes
00112 //#! that make up the module.  The <note role={tip,caution,warning}> tags
00113 //#! will be useful for this, for example:
00114 //#!
00115 //#!   <note role=tip>
00116 //#!      See  Foo.h if you want to fully understand all of the options
00117 //#!      available for creating Foo objects.
00118 //#!   </note>
00119 //#!
00120 //#!   <note role=warning> Don't even think about iterating through
00121 //#!     large Foo objects (80 MB or more) without first consulting
00122 //#!     FooIterator.h!
00123 //#!   </note>
00124 //#!
00125 
00126 // </module>
00127 
00128 
00129 } //# NAMESPACE CASA - END
00130 
00131 #endif