Friday, December 26, 2014

A Review of Geometric Features and Visual Models for Radial Graph Presentation

This evening, I've been endeavoring to develop something of an idea as to how CLIM may be applied for drawing hyperbolic graphics onto CLIM panes -- focusing on McCLIM,  for such application, namely as with regards to the MetaCommunity.info (MCi) fork of the original McCLIM codebase.  Although this initial study would be non-trivial, namely to my own limited academic knowledge of mathematical systems, but it's my hope that I may be able to trudge my way through this study, to develop something of an idea for a functional application of existing theory about hyperbolic graphs -- if not the broader algebraic topology -- namely towards a design of a new graphing component for McCLIM.

Reading [KobourovS2005], this evening, the authors denote two popular approaches for mapping a graph in the hyperbolic space onto the Euclidean plane:

  • Poincaré Disk Model
  • Beltrami-Klein Projections.

There are two additional approaches denoted by [ParksH]

  • Poincaré Half-Plane Model
  • Hyperboloid
This article, as a short collection of notes, will presently focus on the presentation in [ParksH]

  • Beltrami-Klein Projections
    • Named after the work of Eugenio Beltrami and Felix Klein (ca. 1870)
    • Euclidean space is constrained by a disk, for purpose of the projection
    • Points are defined within the circumference of the disk
    • Lines are presented as chords between points
      • For points A, B not on the circumference of the disk, the geometric extension of each of A and B to the circumference of the disk -- respectively, to points P, Q -- may be required for some calculations -- such as to calculate the projected distance between points A and B:
        • d(A,B) = 1/2 |log (AP*BQ) / (BP * AQ)|
      • For a A  situated on the circumference of the disk, A is denoted as an ideal point
    • The pole C for two points A, B, is the point on the Euclidean plane at which the lines defined as tangent to each of A and B meet in an intersection. C, of course, is not within the space of the disk
    • Concept of parallelism: Lines are parallel if they do not intersect within the area of the disk
    • Concept of perpendicularity: 
      • For line M being a diameter of the disk, N is perpendicular to M  -- in the hyperbolic projection -- if N is perpendicular to M in a a sense of the Euclidean coordinate space
      • For lines M and N not being a diameter of the disk: N is perpendicular to M, only if the geometric extension of N beyond the area of the disk would intersect the pole of M.
    • Angular measure: TBD
  • Poincaré Disk Model
    • Named after the work of Henri Poincaré (ca. 1880)
    • Likewise, Euclidean space is constrained by a disk, for purpose of the projection 
    • Likewise, points are defined within the circumference of the disk -- excluding the circumference or boundary of the disk. See also: [TernesM] 
    • For a circle -- as a geometric object -- defined within the hyperbolic projection, the circle has essentially two functional center points -- one for the circle in the Euclidean space, and one for the circle in the hyperbolic space, as projected onto the Euclidean space. See also: [TernesM], which the following sub-points are in reference to
      •  The midpoint of a line likewise has two coordinates -- one in the Euclidean space, and one in the projected hyperbolic space
      • The definition of an angular bisector must also be calculated for the characteristics of the projection
    • Two types of line, for points A, B:
      • A diameter of the disk, passing through points A, B
      • An arc passing through points A, B and ending as orthogonal to the circumference of the disk (see also: [VenemaG] p. 97, ch. 14) 
    • Concept of parallelism (arcs) : That the arcs M, N do not intersect at any point within the disk
    • Concept of perpendicularity: That two lines M, N meet orthogonally i..e at a right angle (See also: Angular measure)
      • A relatively easy matter to calculate, computationally, for two lines that are diameters in the Poincaré Disk projection
      • Less relatively easy to  calculate, if either or both of M and N is an arc
    • to calculate the projected distance between points A and B, with ideal points P and Q:
      • d(A,B) = |log (AP*BQ) / (BP * AQ)|
      • This is expressed in [VenemaG]  (p. 97, ch. 14) as follows:
        • d(A,B) = |ln(AB, PQ)|
    • Angular measure: "To measure the angle between two lines in a Poincaré Disk, you measure the Euclidean angle between their tangent lines."
      • TBD: Some ambiguity as to what the term tangent line may mean, in that definition. In any interpretation, that definition would be constrained only ti arc type lines within the disk
        • If the term refers to a line draw tangent to a point on the circumference of the disk,  and external to the circumference, but for any line AB, there would be two tangent lines in that interpretation. Those lines, of course, would be parallel if AB describes a diameter of the disk.
        • If the term refers to a line drawn tangent to each endpoint of an arc -- namely, at the points where the arc meets the circumference of the disk, ortogonally -- then for any line AB, there would be only two such tangent lines, both meeting on the Euclidean plane, at a point within the circumference of the disk
        • In either interpretation, there would be -- respectively -- four or two individual tangent lines for each arc. It would then be effectively impossible to measure the angle between tangent lines for two intersecting arcs
        • In a third interpretation: The term tangent line, in that application -- and namely, for an arc type line -- might refer to a line drawn tangent to the arc, at the point of the intersection. For a non-arc type line, the line itself might be used for the determination of angle, at the intersection. This is probably the correct interpretation of the term. See also: [WolframP]
    • Limit Rays: Arcs that meet at a common point on the circumference of the disk [WolframP]
  • The author describes a method for projecting a Beltrami-Klein Projection onto the Poincaré Disk Model


Of course, the hyperbolic trigonometric functions may have some applications in a graphing model for information visualization. See also: [KobourovS2005][KobourovS2012]

For a more in-depth analysis of the geometry of the hyperbolic space in the Poincaré Disk projection, see also: [SchutzA]

The qualities of the abstract geometric spaces of these projections would certainly make for a lengthy study, to the student of mathematics. Concerning a question of how these projections may be applied for information visualization, there are some many illustrations provided in [KobourovS2005] and [KobourovS2012]. Perhaps it may be well to consider some additional models, furthermore -- not limiting the discussion to the set of known hyperbolic projections. 

Certainly, there is a significant variety of information visualization models  defined in the information sciences. [HermanI] Particularly, either of the Cone Tree / Relative Disk Tree (RDT) projection models proposed in [JeongC] or the model proposed in [MelanconG] might serve to define a visually appealing graph with a minimum of spatial compaction, in a visual model for a directed acyclic graph (DAG). 

Towards development of an ontology model, such as may be suitable for construction of a DAG view: In an application of SKOS,  as within an OWL ontology model, it may be advisable to ensure that every object property defined in the ontology will be a subclass -- whether directly or indirectly -- of exactly one of the object propertiesskos:broader or skos:narrower, With that level of consistency in an ontology, and given any single individual instance M1 within the ontology, it would be possible to define a simple algorithm for computing the descendants of M1 by following the graph of skos:narrower relations -- directly, or as the compliment of skos:broader - for all property expressions within a specific instance of applying the graphing algorithm. to the ontology, selecting each property of which M1 would be a subject, then subsequently taking each object of the relation as the subject for a subtree, for any number of object properties selected in any one instance of applying the graphing algorithm -- the graphing instance being constrained, for purpose of brevity, constrained to any number of generational iterations of the algorithm.

Of course, although the graph display procedures might be the most time-consuming features to design for an ontology visualization system -- as to display any single structure of any single graph of individual instances and their object property relations, within an OWL ontology -- however, a graph itself may not serve to convey all of the information presented in an ontology. 

In at least, a complimentary table/page view model might be applied, as to create a focused view for display of ontologically structured information for any single individual instance within the ontology. The table/page view might be applied, moreover, as to allow for a convenient editing onto the set of ontology properties defined to any single individual instance. 

Considering the effective depth of complexity that this article has now arrived to, this article will conclude at the simple remark: "TO DO: Study"

Some additional works were discovered, during the research for this article, namely as with regards to hyperbolic projections onto the Euclidean space. [ChepoiV][BowditchB]. 

[KobourovS2005] Kobourov, Stephen G and  Kevin Wampler. Non-Euclidean Spring Embedders  (2005)
[ParksH] Parks, Hal. The Poincare Disk Model and The Klein—Beltrami Model.
[VenemaG] Venema, Gerard A. Exploring Advanced Euclidean Geometry with Geometer's Sketchpad. Archived
[WolframP] Wolfram MathWorld. Poincaré Hyperbolic Disk
[SchutzA] Schutz, Amy. Hyperbolic Functions.
[TernesM] Ternes, Megan. Tangent Circles in the Hyperbolic Disk
[KobourovS2012] Kobourov, Stephen G. Spring Embedders and Force Directed Graph Drawing Algorithms (2012)
[HermanI] Herman, Ivan , Guy Melançon , and M. Scott Marshall. Graph Visualization and Navigation in Information Visualization: a Survey
[JeongC] Jeong, Chang-Sung and Alex Pang. Reconfigurable disc trees for visualizing large hierarchical information space. See also: [Related]
[MelaonconG] Melançon G and I. Herman. Circular Drawings of Rooted Trees
[ChepoiV] Chepoi, Victor et al. Diameters, Centers, and Approximating Trees of δ-Hyperbolic Geodesic Spaces and Graphs
[BowditchB] Bowditch, B. H. Relatively Hyperbolic Groups

Wednesday, December 17, 2014

State of the MetaCommunity McCLIM fork - Apps "OK," fonts "Up in the air"

In my own small efforts in software programming, this year, I've made a fork of McCLIM -- a short overview provided in a previous 'blog entry, here at my DSP42 web log. It's been to nothing too sensational, as yet. I've made simply a few maintenance updates, and have added a dependency onto the mci-cltl-utils software system -- that much, as for applying a DEFCONSTANT* macro within McCLIM. 

Certainly, there are still some more maintenance updates to develop onto the fork, before getting along to any new developments onto McCLIM. In that regards, the last issue that I'd observed of it was that the font selector example is failing. It would appear to be due to something in regards to the interface onto the fonts table in CLX. Perhaps, that may easily resolved, insofar as the the present state of the source tree.  I think it serves to call some broader concerns to mind, however, insofar as developing an application architecture for Common Lisp desktop application development, within a contemporary computing environment.

Broadly, I've been using the Sharplispers CLX fork of Texas Instruments' original CLX codebase, and the CLX backend for McCLIM. I've tested a number of the applications provided in McCLIM, using the CLX backend. Specifically: The McCLIM listener, inspector, and debugger can be verified as running successfully, with that edition of CLX and on SBCL 
1.2.5.76-65a44db. Furthermore, the Scigraph application has been updated to run by-in-large successfully, on that same platform, although again there are some maintenance issues with it.

I've also tested Climacs, on that platform. It runs successfully, too.

I'd tried applying the GTK Cairo backend for McCLIM, but without a lot of success in that port, presently. With some regrets, that may serve to make it more difficult to apply McCLIM onto mobile platforms. I had hoped that the GTK Cairo backend might've made a good component to apply for McCLIM on an Android platform, and well it still may. Presently, if it does not successfully run on so much as a contemporary Ubuntu Linux platform, then there's not much to show for it, at present.

One superficially minor change now developed in McCLIM: In regards to CLIM's multiple-value-setf behaviors, it should now be  portable onto ECL and CCL (ARM architecture), as well as SBCL (amd64) insofar as free/open source Common Lisp implementations. 

With regards to fonts: When adding a set of ASDF system definitions to the fork that I've made of the original Garnet source tree, I'd observed that Garnet is now extended with Truetype font support, such that utilizes CL-Vectors and extensionally, ZPB-TTF for providing a support for TrueType fonts onto CLX . The clx-truetype system may be applied not exclusively onto Garnet, though it is integrated with Garnet as in the gem-font-methods file in the same source tree.  One might hope that it would be fairly trivial, to apply clx-truetype likewise onto the CLX port in McCLIM. Insofar as with regards to fonts and typesetting in CLIM itself, there -- I think -- is one of the broader concerns of the matter. To a few superficially simple questions:

  • How may it be possible to provide functions for denoting superscript or subscript typesetting, in CLIM?
    • If not, then how may such functions be defined effectively onto McCLIM?
    • To what practical ends may such developments be focused?
  • May it be possible to implement the entire Cascading Stylesheets visual formatting model onto CLIM? Specifically, of CSS 2.2?
    • Note: `vertical-align` and related properties in the CSS model for inline blocks
  • Extensionally: How may it be possible to implement an entire MathML interface onto McCLIM?
Such questions might seem trivial, at the outset.

If the CSS 2.2 visual formatting model may be implemented onto McCLIM, perhaps it may be implemented as to extend of MetaObject Protocol. Hypothetically, any one or more metaclasses may be defined as to allow for a modular  implementation of the CSS 2.2 visual formatting model, such that the implementation may also be portable onto XSL Formatting Objects (spec version 1.1). Sure, it would be nothing too conceptually original, to develop an application protocol that may extend of both and that may be integrated with McCLIM, furthermore -- even insofar as for representation of text according to textual formatting specifiers. Historically, there's also DSSSL

XSL-FO and DSSSL may be particularly suited to a page-oriented media, if not specifically a page-oriented model for graphical user interface design. Insofar as page-oriented media in CLIM, of course there's also the McCLIM PostScript backend

Orthogonally, an implementation of SVG onto McCLIM may seem pragmatically "Out of the question," at this time. Though it would serve to keep pace with contemporary widget toolkits defined in C and C++ -- such as Qt, GTK, and Cairo, all of which provide support for rendering of graphics developed in a medium of SVG -- however, it may represent another distinctly non-trivial design issue to approach in any single fork onto McCLIM.

Of course, the design proposed of the Dobelle-App system -- as specifically with regards to development of mobile  applications in Common Lisp -- it would require that McCLIM or any other single graphical user interface toolkit would be suitably applicable in Common Lisp on a mobile platform, as well as on a desktop platform -- furthermore, beyond simple "Proof of concept" implementation. If a framework may be developed and applied for CLIM applications on desktop and mobile platforms -- not only for backing of a thesis article, but furthermore as a framework for commercial application development -- it would well need to be provably applicable in a commercial domain, in every feature of such a framework.

Still, such a matter may seem trivial, at the outset -- and well, there are so many novel things to take to attention, otherwise?

A succinct index onto dependencies of Dan Lentz' cl-ctrie

A succinct index onto dependencies of Dan Lentz' cl-ctrie

[To Do: Insert, here, a lengthy doctoral overview about data structures for indexing and search within digital object systems. Include a very length bibliography. No too far sidebars about RDF, OWL, and so on. "Keep it within the lane"]

Ed. Note: These may be available via quicklisp. Alternately, one may apply an SCCM tool manually, to download the newest source trees representing each respective project.
  • nibblesA Common Lisp library for accessing octet-addressed blocks of data
  • ironclad - A cryptographic toolkit written in Common Lisp
  • cldoc -  documentation tool; alternate to Albert
  • unicly - UUID implementation [RFC 4122]
  • uuid - (and another) (code alignment?)
    • Shared dependency: ironclad
    • Additional dep: trivial-utf-8 (see also: Closer-Common, cf. the illustrious 'rune' data type, towards code alignment)
  • split-sequence - "self explanatory"
  • Informatimago Public Common Lisp Libraries - namely Informatigo 'heap' system)
  • cl-irregsexp - regular expressions, alternate to cl-ppcre's Perl-like syntax (code alignment?)
  • Stefil - testing framework  [old homepage][new homepage - refer to 'Repository', 'User Guide' other tabs on page]
    • Also needs hu.dwim.asdf
  • :hu.dwim.serializer - as with the Stefil project, refer to 'Repository' and other tabs on page.
    • Likewise hu.dwim.common
      • Likewise, Anaphora
      • Likewise, hu.dwim.common-lisp (code alignment?)
      • Likewise, metabang-bind (but what kind of an SCCM system does this project use?)
    • Likewise, hw.dwim.def
    • Likewise, hw.dwim.syntax-sugar (with a grain of salt)
    • Likewise, hw.dwim.util (code alignment among utility systems?)
    • ... :hu.dwim.defclass-star
  • CL-STORE - also an object serialization system
  • Osicat - compatibility layer onto OSI/POSIX/.... May be common (code alignment)
  • CL-PPCRE - Regular expressions in a syntax resembling of perlre (PERL). May be common (code alignment)
  • iterate - Extensible alternative to CL:LOOP and other iterative forms defined in CLtL2. May be common (code alignment) 
  • Alexandria - a popular bundle of utility forms, in Common Lisp
  • Selected subprojects of the Closer Project
    • Closer-MOP - common
    • ContextL - Towards context-oriented programming in Common Lisp
....and that's all for the dependencies, at that level of study.

Most of those projects are available via Git. Exceptions:
  • CLDOC may be downloaded in its source code, with CVS:
    cvs -d:pserver:anonymous:anonymous@common-lisp.net:/project/cldoc/cvsroot checkout cldoc
  • Anaphora also uses CVS
    cvs -d:pserver:anonymous:anonymous@common-lisp.net:/project/anaphora/cvsroot checkout -d anaphora src
  •  UUID is available as a gzipped tape archive (i.e. *.tar.gz) (see UUID homepage)
  • The Trivial UTF-8 project uses Darcs:
    darcs get http://common-lisp.net/project/trivial-utf-8/darcs/trivial-utf-8
  • The DWIM.hu projects (Stefil, serializer, etc) also use Darcs
    darcs get http://dwim.hu/live/hu.dwim.stefil/
    darcs get http://dwim.hu/live/hu.dwim.serializer/
    
  • Iterate also uses Darcs
    darcs get http://common-lisp.net/project/iterate/darcs/iterate

Optionally, Darcs can be applied with the '--lazy' argument to 'darcs get', as to create a Darcs repository applying a copy on demand methodology for changeset data. Applying this argument, the net time required for the 'darcs get' command may be minimized.

Wednesday, December 10, 2014

Introducing the Mercantile Store of the MetaCommunity Project

I've developed a small aStore storefront at Amazon.com Associates -- the  Mercantile Store of the MetaCommunity Project (presently in its edition 1) -- including a small list of accessories I personally would trust for application in outdoor environments, such as for conservationism or the simple recreations of camping out, if not furthermore for day hikes and so-on.

Of course, with regards to camping stoves, it should be noted: That the same regulations would apply as with regards to campfires. In the US forests, one may consult the nearest, official US Forest Service Ranger Station for more information. Typically, the permits are available for free, and would be accompanied with a wealth of useful information for campfire safety. There are also some digital resources about campfire safety, such as published by the US Forest Service, in California's Sequoia National Forest.

Proceeds from the Mercantile Store will be applied for continued development and maintenance of web resources of MetaCommunity.info There is not, as yet, a 501(C)(3) or other non-profit registration for the development of MetaCommunity.info. Candidly, it may be difficult to register it as a non-profit organization, under any exact specifications in US tax code, though it is essentially a not for profit organization. Pending any further, formal development of the MetaCommunity.info organizational architecture, the author personally will see to it that any proceeds from the aStore will be applied for continued development and maintenance of web resources of MetaCommunity.info.

MetaCommunity.info is a web resource still under development. My own initial idea for the development of MetaCommunity.info was that it may serve as a sort of meta-resource for knowledge sharing, as with regards to concerns of life and lifestyle -- none too aligned to any single social networking platform, however, thus existing as a sort of "Meta-Community." Unfortunately, the development of the web resource has been stalled, pending further resolutions in certain nationalist and quasi-national concerns in the world. Furthermore, the initial design concept has undergone some moderate evolution, in this year.

In the outlook, presently, MetaCommunity.info would be -- in one part -- a projects hub for selected projects about math and engineering, and furthermore a hub for projects developed as towards some humanitarian concerns, and conservationism, and tourism. I've begun to develop a design for a single portal under each such concern. However, I am presently unable to develop any single schedule for such projects. The ink is just dry, on the outline itself, and -- myself -- it seems that I must certainly search for another place of residence, before I may be able to begin to focus about anything so technical and involving.

So, but that's what there is so far, for it --  a web store and a resource for campfire safety.

Please, Tread lightly.

Notes - MetaCommunity.info fork of McCLIM

Towards developing an application framework for supporting a platform-agnostic approach to development of graphical desktop applications in Common Lisp, I've made a fork of the McCLIM codebase, organizing the codebase under the MetaCommunity projects group at Github. Corresponding with so much as the maintenance updates in the fork, I've also begun to keep an issue tracker with YouTrack, under the hosted YouTrack InCloud service, At this time, I would not request contributions about of those endeavors. This is simply a note that I would like to share, regarding such existing work.

Insofar as keeping track of the aims and goals of the development of the MetaCommunity.info (MCi) fork of McCLIM, whereas the project comprised of the fork does not yet "Fit" into any specific heading within the two main MetaCommunity.info projects groups -- respectively, the Clyde projects, named after the Firth of Clyde, directed  mostly towards applications in mathematics and electrical engineering, and the Fourier projects, named after Charles Fourier, those to be focused mostly about literacy, tourism, and ethical conservationism, so far time and focus permit -- so, instead of documenting this small effort, presently, at the MetaCommunity.info work journal,  instead I thought it would be appropriate to publish this outline, here at DSP42.

So, with that much of adieu, my notes about the MCi McCLIM fork.

The main points of focus in the development of the MCi McCLIM fork are as follows:
  • Maintenance updates
  • Documentation
  • Usage cases
    • Scigraph
    • Extensions: ??? 
      • Usage cases on the BeaglBone Black platform (ARM) in applications of BBB TFT LCDs
        • Application: Multi-headed display for desktop measurement/analysis system
        • Application: Small electrical systems monitor (Solar electrical system)
        • Additional notes:
          • Deterministic timing in RTOS systems
            • Memory locking
            • Process scheduling
            • Garbage collection in the Common Lisp implementation
            • Kernel architectures (onto Linux kernel space)
            • See also: Realtime applications of Java / Realtime JVM implementations
      • Extensions in development of another mathematics platform in Common Lisp
        • Polar coordinate graphing *
        • Graphing for objects on Euclidean and Complex planes *
        • Measurement Units (See also: Igneous-Math)
        • Phasor diagrams *
          • EE Applications (AC systems; signals synthesis; signals analysis)
          • Applications in classical mechanics
        • Linear algebra *
          • Trivial concept: Presentation type for a matrix view of Common Lisp arrays
          • Less than trivial concept: Differential analysis, with corresponding presentation types
      • Extensions for systems modeling and interactive model design, in Common Lisp
        • URIs
        • XSD
        • XMI
        • UML Primitive types)
        • MOF
        • UML metamodel
        • SysML metamodel
        • ODM metamodels (RDF, OWL, Common Logic)
      • Extensions for a CORBA-centric desktop application framework
        • ORB monitor
        • IDL designer (IDE)
        • ??? (TBD)
* See also; Scigraph application, as published in McCLIM (referencing the MCi fork)

Certainly, the development of the fork is focused mostly towards usage cases. Beyond the maintenance updates, there may not be much to add to the McCLIM codebase itself.

Perhaps there may be an opportunity for adding some developer documentation to the codebase, over subsequent changesets in the codebase -- pending development of a suitably comfortable documentation system, perhaps extending of DocBook XML

This, then, would represent the first significant "Note to public" regarding the McCLIM fork developed under MetaCommunity.info.

Thus far, the fork is representative of the source tree cloned from Timothy Moore's original McCLIM source tree, with some changes merged in from Andreas Fuchs' fork, as was developed onto the original McCLIM CVS repository. I've also made a small number of maintenance updates to the source tree, including a short effort for a portable multiple-value setq (needs testing), and a defconstant* form to avoid errors on repeated redefinition of constant values.

Subsequently, the fork may also merge the changes developed under Robert Strandh's McCLIM fork. I'll make a note of that in my own Diigo bookmarks, and here.

This effort is, at the outset, mostly an academic matter. I cannot imagine any immediate commercial applicability about such work. Perhaps it might seem, then, as though it could represent something of a quixotic kind of "lark", in the conformity-oriented social network of "the modern." Regardless, there is the source tree as updated, to-date.

Saturday, December 6, 2014

Towards a Design of a Parallel AC/DC Mains System for Single Residential Application

On a "research lark" about solar energy systems, today, I've found a resource published by Emerson Network Power, such that I would like to make a small note about, here in my DSP42 web log.

 Considering:
  • Solar energy systems produce DC signal -- as before any conversion to AC via diodes, inductors, transistor driven voltage regulators, etc -- as possibly before any conversion back to DC, then, as when for driving digital electronics and DC appliances
  • DC electrical signals may be suitable for decentralized applications not requiring any unspecific number of long-distance electrical transmission lines
  • That towards a design for a residential DC/AC parallel lines system, insofar as the DC line system, there may be an analogy found in data center architectures

Found Resources:
  • Murrill Mark  and B.J. Sonnenberg. "Evaluating the Opportunity for DC Power in the Data Center" Emerson. 2010
    • Notes
      • Modular Design
        • 480 V AC mains (common)
          • Step-downs to 208 V AC
        • Cooling system (p. 7)
        • PDUs, BDBC systems
          • Topology of power distribution network
          • Switched-mode power supplies may introduce harmonics of signals on AC lines (p. 6)
            • Affects accumulate in neutral line
              • Mechanical model: TBD
            • Desultory effects:
              • Power loss
              • Source of heat energy within data center/components
            • Related concept: Total harmonic distortion within power distribution network
          • Variations in system load 
            • At interfaces onto three-phase AC systems: Timing/scheduling of load changes within data center, onto phases of three-phase AC system (noted, p. 6) (?) ideal, to minimize power loss and generation of heat energy
              • Mechanical model: TBD (Three-phase AC)
            • See also: Phase Balancing: The Last Few Inches of a High-Efficiency Power System (referenced, p. 7)
            • Scheduable load changes (macro model):
              • Instance: Current loads induced for battery charging within uninterruptable power supply (UPS) systems
              • Instance: Current loads induced due to computing loads, in application of computing resources within batch computing models
            • Unschedulable load changes (macro model):
              • Instance: Computing loads resulting of direct user agent interactions
              • Mitigating concern: Interactive network services can be localized to individual data center elements
        • Energy consumption
          • Data center components - Digital computing
          • Battery charging in UPS systems
      • DC voltages
      • Safety and standards

Resources at a beginning of this research arc:
  • News article Worlds Largest Solar Plant Goes Online Using 9 Million Solar Panels
    • A large scale, grid-centric solar energy system recently developed by PG&E
  • Concepts towards applicability (residential energy systems): 
    • Concept: DC motors
      • (TBD)
      • Industrial applications
        • ShurFlo DC centrifugal pump, from ShuFlo industrial
          • Possible applications in decentralized solar/battery systems for agriculture, industry, and recreational maritime systems
      • Residential/Utility applications
        • Battery-operated/cordless home utility equipment and construction tools
    • Concept: DC appliances
      • (TBD)
      • Common:
        • Residential air conditioning and heating systems
          • Consdenser and motor in air conditioning systems
          • Heating coils
          • Swamp coolers (humidity)
        • Residential air circulation (e.g. ceiling fans)
        • Food refrigeration
        • Lighting appliances
          • Filaments (AC lighting)
          • "Warmth" of lighting model
    • Concept: DC power supplies within/for home entertainment systems
      • Video
      • Audio
      • (TBD)
  • Previous article in solar electrical series, here at my DSP42 web log

Wednesday, December 3, 2014

Free Book about Op-Amp Applications, from Texas Instruments

I was looking for a solid reference resource, this evening, as with regards to design of frequency-domain active filters in audio and signaling applications. I found the following the eBook. It seemed that it would be fit to share a note about, here at my DSP42 web log. Published by Texas Instruments in 2002, the eBook is titled, Op-Amps for Everyone.

Across all of 464 pages of PDF format text, the eBook provides a comprehensive introduction to op-amps -- now available in free, PDF eBook format. The eBook is published by Texas Instruments, but provides a vendor-agnostic, essentially non-proprietary view with regards to op-amp applications.

This eBook provides introductions to concepts and applications of op-amps, with corresponding mathematical formulas throughout. As a small sampling of the topics addressed in the eBook:
  • Chapter 3 of the eBook addresses op-amp applications in a generic sense, focusing on methods for applications of op-amps within common kinds of amplifier circuit, including: Inverting amplifiers; non-inverting amplifiers; differential amplifiers; video amplifiers; etc. 
  • Chapter 4 of the eBook provides a contrast between single-supply and dual-supply applications of op-amps. Chapter 15 of the eBook is dedicated to oscillator designs, for generating sinusoidal waveforms. 
  • Chapter 16 of the eBook is dedicated to discussions of active filter designs. 
The eBook addresses a number of concepts that might be addressed, in parallel, in the course material of the DeVry University Online ECT-246 course. The eBook also provides some information about some additional concepts, such that may be encountered -- broadly -- within a context of design and analysis of op-amp circuits.

To the aspiring software programmer, perhaps the eBook may serve to provide a convenient, singular reference model for design of an electronic design automation (EDA) tool for amplifier design and analysis in frequency-domain applications.